Jevは文章や業務データを読み取り、分類・採点・条件判定の結果を確率付きで返すAIモデル。返り値はソフトウェアの条件分岐に利用することを想定しており、プログラムが明確に判定して複雑な制御に応用できる点が特徴。本記事はJevの概要を、従来型LLMやAIエージェントとの違いという観点から整理して解説する。
AIがコードを書くようになり「認知負債」が課題として認識されつつある一方、そもそも人間が全てを認知すべきなのかという議論もある。本記事は「技術的負債に向き合うConference 2026」の聴講を踏まえ、認知負債を「仕組みを人間が認知しないまま稼働しているコードが存在すること」と定義し、その問題点を考察する。
AIエージェントに改善を繰り返させても、プロンプトの加筆や出力の整形に留まり、最初の設計を見直せず停滞することがある。本資料では、業務AIワークフローの構築・改善で経験した課題と関連研究をもとに、深層学習の訓練ループとの対応を手がかりとして、自己改善を支えるハーネスの設計を解説する。
筆者が約1年半にわたり個人の開発で育ててきたAI開発フローについて、Claude Codeを実務に取り入れ、サブエージェントによる思考レビューなど試行錯誤を経て現在の形に至るまでの変化を紹介する。
データ基盤チームが、定型の分析依頼への対応フローをAIエージェント前提に組み替えるPoCを紹介。AIに自由にSQLを書かせると結合キーの取り違えや指標定義の揺れで「それっぽい数字」が返るため、集計ロジックはdbtのymlに定義したセマンティックレイヤー（Lightdash）に委ね、AIには仕様書の解釈と言葉と定義の橋渡しだけを任せる構成にした。LightdashはOSS版をAWS上にセルフホストし、REST APIを叩く自作MCPサーバー経由でAIからexplore・チャート作成を操作する。選定理由、セマンティックレイヤーがガードレールになる仕組み、定義が網羅できない部分を補うcustomの口と昇格ループ、現時点の運用状況と展望を述べる。
Claude Code などのコーディングエージェントにより一人でフロントから運用まで組めるようになった一方、ハッカソンで最初に悩んだのは「何を作るか」だった。AIハッカソンで優勝した経験を基に、アイデアの出し方を述べる記事。
OpenSpec はソフトウェア仕様の作成・管理のための軽量で設定可能なフレームワーク。作りたいものを spec として記述し、チームとコーディングエージェントの認識を揃えながら、要件の洗練、仕様が正しい対象を記述しているかの検証、実装が仕様に一致するかの確認を行う。Claude Code、Codex、Cursor、GitHub Copilot、Gemini CLI など多数のツールと互換で、explore / propose / apply / verify / archive というワークフローコマンドを提供する。
生成AIを業務に組み込む際、生成→評価→実行の流れでは、実行しないと評価情報が得られない処理に対応できない。実行を段階的に許可し、何を観測し、その結果から次の実行範囲をどう判断するかというHuman-in-the-loopのゲート設計の必要性を論じている。