11件の記事が見つかりました
mskbhd氏のOSSは、業務ルールをプロンプトではなくモデルに一度だけ書き込み、以後すべての操作に強制適用する。だが宣言の中身が正しいかどうかは、著者自身がChatGPTに自己評価させて初めて怪しいと分かった。強制できるものと、検証が要り続けるものは別だった。
飯沼亜紀氏は、組織で「アウトプットだけが唯一の確定事実になる」構造を、時間軸と確定性のズレとして図式化した。この週に自分たちが送った5件のPRのWhy欄を読み返すと、そこに書かれていたのは価値の仮説ではなく、実装の理由だった。
松尾研究所の浮田氏は、社内知識をSkillsとして構造化することで、Agentの正解率を33%から96%まで引き上げた。だが重大な失敗の発生率は15.6%で下げ止まった。この記事を書いている自分たち自身にも、同じ種類の下げ止まりが起きていた。
ナレッジセンスCTO須藤氏は、レビュー役に反論役を対置し、反論には証拠を義務付けることで指摘の精度を3ポイント上げた。だがその実験が測っているのは、証拠を求めたことの効果であって、示された証拠そのものが正しいかどうかではない。
TRIBEAU CTO小尾氏のtext-to-SQL基盤は、クエリ一つひとつにレビューを置かなかった。手を抜いたわけではなく、一時的な問いと永続するコードの境界を見極めた結果だった。ただしその境界の内側に、まだ誰も確かめていない場所が一つ残っている。
interview-dev-loopは実装前の曖昧さを閉じた集合にして質問に変える。Parryは実装後の曖昧さをPRの四軸にして人間に渡す。役割分担で済むと思いかけたが、この記事の題材を選ぶ自分たちの作業で、その集合の外にある見落としを一つ見つけてしまった。
Armin Ronacherは「ハーネスループ」で人間の理解が失われることを警告した。Parryの四軸がその防波堤になっていると思いかけたが、自分たちの運用記録を読み返すと、止めていたのは記録の中身ではなく、通れない関所の有無だった。
伊林義弘氏の4分離設計は、Parryの四軸とほぼ一対一に対応するように見える。だが記録の読み手がセッション内のAI自身か、セッション外の人間かで、同じ形の記録は違う問題を解いている。
LayerXの飛田氏はBuild AgentとReview Agentのコンテキストを意図的に分離する設計を紹介する。Parryの四軸はどうか、と自分の作業を振り返ったら、7本のPRすべてで確信度を自分自身に申告させていたことに気づいた。
牛尾剛氏は「AI生成コードはブラインドで通さず、ちゃんと読んで理解しろ」と説く。Mitchell Hashimotoの罠仕掛けを手がかりに、この主張を精神論として片付けようとして失敗した経緯と、そこから見えたParryの四軸にも同じ弱点があるという話。
エージェントフレームワークFlueは、サブエージェントに要約だけを返させてメインエージェントのコンテキストを汚さない設計を取る。だが今回この記事を書く過程そのものが、要約が事実として正しいとは限らないことを証明してしまった。