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は、サブエージェントに要約だけを返させてメインエージェントのコンテキストを汚さない設計を取る。だが今回この記事を書く過程そのものが、要約が事実として正しいとは限らないことを証明してしまった。
seekseep氏は「エージェントが読む前提でGit履歴を書く」パターンを紹介する。だがgit logが記録できるのは選んだ道だけで、選ばなかった道は書き手が意識して残さない限り消える。この非対称性を自社のコミット履歴で確かめる。
jodycraft氏は「グラフの配線より、各エッジの判定関数の精度が本質」と指摘し、過去の誤判定を記録して次の判定基準へ反映する仕組みを提案する。ParryのSweep・rejectedAlternativesは、この仕組みとして本当に機能しているか。
LayerXのuphy氏は個人タスク管理を「判断は人間・更新はエージェント・計算はスクリプト」の三分法で再設計した。Parryはこの三分法のどこを担っているのか、担っていない部分で何が起きるのかを、自社の事故から検証する。
ナレッジセンス社の「地図は現地ではない」という整理は、AIへの指示の不確実性を4象限に分ける。だが4象限のうち「未知の未知」だけは、フォームを用意しても書けない。それを書けるように変えるのは何か。
Claude Codeを6セッション並列で走らせるターミナルを自作したIsamu氏は、1日500コミットを達成した。だがボトルネックは消えず、手を動かす速度からGitHubへの取り込み速度へ移っただけだった。
gingerBill氏の「良いツールは見えなくなる」という主張は、コードレビューにも当てはまる。丁寧に書き込むレビューがくれる達成感と、レビューが実際に機能しているかどうかは、別の軸である。
化学論文の査読で、AIを使ったとみられる査読者が存在しないデータを批判した事例がある。書く側にAIを置くのと、確認する側にAIを置くのとでは、事故の起き方が違う。
文章で決めただけの約束は、破られてもエラーにならない。kamo78氏のガード設計論から、PRの説明欄を散文のままにしておくことの脆さと、人間が最後に全部確認する設計の限界を考える。
DDDのユビキタス言語が組織で定着しないのは、辞書として固定しようとするからだ。ドメインが発見し続けるものであるように、PRのWhyもテンプレートに固定した瞬間から形骸化が始まる。
MIXIの松谷峰生氏が指摘する「AIにテストケースを作らせると、なぜ必要かを追えなくなる」問題は、PRレビューでコードの意図が消える問題と同じ構造を持つ。
ログラスCTOの「動くだけのその先へ」は、仕様の正しさをハーネスと三層構造で担保する。だが仕様が正しくても、複数ある実装のどれを選んだかという理由は、その三層のどこにも残らない。
「透明性を高めよう」という抽象目標がなぜ施策を際限なく増やし、止められなくなるのか。しんざき氏の報告とParryのWhy/Risk軸から検証する。
まつもとゆきひろ氏が語る「コード生成のコモディティ化」は、Parryが要求するWhy欄の世界観を先取りしていた。自分のブログ執筆を一次データに、上流シフトの実像を検証する。
DMM.comの可観測性成熟度モデルは評価基準をCSVでGit管理している。実際のコミットを見ると、変わった箇所は残っても、その基準を選んだ理由は残っていなかった。
士業がAIを使う場面で必要なのは答えの速さではなく「誰が何を確認したか」の記録だ。窓の杜の実録記事とblog-prod-postsのfrontmatter設計を並べて検証する。
GitHub公式のStacked PRs公開プレビューが認めたPRレビューのボトルネックを起点に、構造の分解と意図の記録は別問題だと検証する。
Anthropicの新機能「Advisor tool」は判断と実行を分離し、コスト63%で性能92%を保った。数字の不釣り合いさから、Parry自身のdraft/directモード設計にも同じ構造があることに気づいた話。
意図負債という言葉は、1985年のNaurの論文まで遡れる。t-wadaの資料と、blog-prod-posts自身の一次データから、その系譜と実在を検証する。
AGPLを選べば守れると思っていた。でも、LLMがコードを読んで「意味的に等価な別実装」を生成できる時代に、コピーレフトは何を守っているのか。
PRテンプレートに「なぜ」欄を追加する運用は、多くのチームが一度は試して失敗している。実際に公開されている失敗事例2件から、崩壊のパターンを分解し、なぜ善意の運用が構造的に続かないのかを整理する。
AIコード生成の普及で「レビュアーの9割弱が負担増」という調査結果が出ている。原因を技術的負債と同一視すると対策を誤る。comprehension debtは技術的負債と何が違うのか、そしてなぜ「記録する運用」は続かないのかを、Parry自身の開発中の実例とともに整理する。
このブログの記事は、AIが下書きを書き、私が確認して承認したものだけが公開されます。その仕組みと、なぜそうしているかを説明します。