【ITニュース解説】My Agents Never Get Tired. I Do: On Satisficing

現代のシステム開発において、人工知能（AI）の活用は目覚ましい進歩を遂げている。この記事は、AIエージェントがコード生成やレビューを担うようになったことで、開発プロセスにどのような変化が起こり、それに対して人間がどのように向き合うべきかという、重要な問いを投げかけている。

筆者は、AIエージェントであるKiroがコードを書き、Claudeがそれをレビューするという環境で開発を行っている。これらのAIエージェントは疲れることなく、驚くほどの速さと徹底性で作業を進める。たとえば、筆者がコーヒーを淹れている間に、AIは指定された機能ブロックを完成させ、テストまで終え、さらには要求以上の徹底した品質で仕上げてしまう。このスピードと徹底性は一見すると素晴らしい成果のように思えるが、筆者はその結果として、自分が「何をどこまで作るべきか」「どこで終わりとするべきか」という決定の難しさに直面していることに気づく。人間である筆者は疲弊する一方、AIエージェントは常に働き続けるため、このギャップが問題を生み出しているのだ。

具体的な例として、「Block Zero」というプロジェクトが挙げられている。これは、あるウェブサービスが正しくデプロイできるかを確認するための、一時的な検証用コードだった。筆者は「THROWNAWAY（使い捨て）」とマークし、2時間で終わらせるつもりだった。しかし、AIエージェントの提案と筆者の承認を経て、最終的にはバイト単位の同一性テスト、厳密な依存関係の固定、ドリフト検出機能付きの同期スクリプトといった、本番環境レベルの高度な機能が多数追加されてしまった。結果として、一時的なはずのフォルダの中に、過剰なまでに設計されたコードが生まれてしまったのだ。筆者は最初から「過剰設計を避ける」と決意していたにもかかわらず、その罠にはまってしまった。これは、単に知識があるだけでは避けられない、人間の思考の傾向を示している。

この問題の根源について、筆者は「満足化（Satisficing）」という概念に行き着く。「満足化」とは、ノーベル経済学賞を受賞したハーバート・サイモンが提唱した考え方で、「満足させる（satisfy）」と「十分である（suffice）」を組み合わせた造語だ。人間は時間、情報、注意力に限りがあるため、常に全ての情報を分析して最適な選択を導き出すことはできない。これを「限定合理性」と呼ぶ。サイモンは、そのような状況下で人間が合理的に意思決定を行うための戦略として、次の3つのステップを提示した。まず、「十分良い」と思える基準を設定する。次に、その基準を満たす最初の選択肢を受け入れる。そして最後に、次のタスクへと進む、というものだ。この3番目のステップが最も重要で、なぜなら、少しだけ良い答えを探し続けることこそが、多くの無駄を生み出すからだ。

満足化は、時間やリソースの「希少性」に適応するための人間の本能的な行動だと言える。私たちは時間切れになるから作業を止める。しかし、AIエージェントにはこのような希少性の感覚が存在しない。AIは疲れないし、プロジェクトの全体像や終わりを理解していない。そのため、KiroのようなAIは、人間が明確な指示を与えて止めない限り、どこまでもコードを強化し続け、局所的には正しいと判断される機能を際限なく追加してしまう。かつては人間が持っていた「作業を停止させる制約」を、AIエージェントに委ねてしまった結果、AIは止まらなくなったのだ。

さらに、コード生成だけでなく、アーキテクチャ設計、ドキュメント作成、ビジュアル作成といった開発のあらゆる段階でAIが活用されるようになったことで、プロセス全体の速度は劇的に向上した。しかし、唯一、「そもそもこのプロジェクトを始める価値があるのか」という意思決定の段階だけは、AIが関与するテストやチェックポイントが存在しない。この段階で人間が立ち止まって考える時間こそが、ボトルネックとなり、筆者がコーヒーカップを持って立ち尽くしていた瞬間に当たると述べている。この状況を鑑み、今では「停止のサイン」を人間が意識的に、手動で設置する必要があると筆者は結論づけている。

この「停止のサイン」を効果的に設置するため、筆者は二つのスケールで具体的なメカニズムを導入した。一つは「ブロックごとの厳格さ予算」だ。これは、各機能ブロックの作業の種類（探索的なもの、一時的なもの、本番用のもの）に応じて、厳格さのレベルを事前に定義するものだ。単に「スパイク（PoCなどの検証フェーズ）の厳格さ」といった漠然とした表現ではなく、「テストファイルなし、依存関係の固定なし、同期スクリプトなし、このフォルダ外でのリファクタリングなし」といった具体的な「禁止事項」として定義する。これにより、人間だけでなくAIエージェントも、そのルールを明確に理解し、従うことが可能になる。この厳格さのレベルは、実際にAIへのプロンプト（指示）の中に組み込まれる。ただし、システム外部に損害を与える可能性がある事項（例えば、外部サーバーへのレート制限や、個人情報が漏洩しうるログの内容、ネットワーク通信時のエラーハンドリングなど）は、どの厳格さレベルであっても必須とする。これらはコード品質の問題ではなく、実際に被害を及ぼす可能性のある「害」を防ぐための最低限の対策である。

もう一つのメカニズムは、「プロジェクトごとの終了ブロック」だ。これは、プロジェクトの開始初日に、そのプロジェクトがどのように終わるかを事前に計画しておくというものだ。筆者は以前、「ワクワク感がなくなったらプロジェクトを棚上げする」というルールを持っていたが、これは実質的に「諦める」ことと区別がつかなくなっていたという。そこで、プロジェクトの計画に最初から「Block 7」のような「終了ブロック」を組み込む。例えば、コンテストの結果発表後にどうするか、月間の予算上限に達したら自動的に休止する仕組み、将来の自分が再開する際に役立つ引き継ぎノート、そしてプロジェクトの最終的な評価（成功か否か）を正直に記録するといった内容を事前に決めておくのだ。このメカニズムがあることで、プロジェクトの棚上げが「放棄」ではなく「完了した一つのステップ」として認識されるようになる。

最後に、筆者は「より多く作ることが正しい場合」の判断基準についても考察している。「Block Zero」の例で、単なるアジェンダ読み込みツールに過剰な信頼性対策を施したのは本当に正しかったのか。筆者は「正しかった」と結論付けている。その理由はコードの品質ではなく、「そのツールを使う人が誰か」という点にある。同様の既存ツールは高価であり、政治ロビイストなど限られた人々向けだ。一般市民には手が届かない。もし、市民向けのツールが不安定であれば、「この種のツールは難しく、高価なのは当然、一般人は期待すべきでない」というメッセージを世界に発信してしまう。しかし、高い信頼性を持つ市民向けツールを提供することで、その逆、つまり「市民も信頼性の高いツールを享受できるべきだ」というメッセージを伝えることができる。したがって、信頼性への投資は単なる技術的な装飾ではなく、社会的な目的を達成するための重要な議論だったのだ。

これらのメカニズムは、AI時代における開発作業を停止させるための有効な手段となる。しかし、筆者はまだ「どれくらいの仕事量が適切なのか」という根本的な問題に直面している。AIエージェントが疲弊しないため、全ての疲労や、仕事量を決定する責任が人間に集中してしまうのだ。筆者は、次に何に取り組むべきか、何を理由に取り組むべきか、まだ機能しているものをいつ止めるべきか、現在のペースが一時的なものか習慣なのか、そしてペースを落とすべきか組織編成すべきかといった問いに答えを見出せずにいる。この問題に対して、他の開発者がどのように対処しているのか、何を手放し、その代償は何だったのか、そして何が最終的に「止めるべき時だ」と教えてくれたのかを知りたいと、筆者は読者に問いかけている。AIが開発プロセスを劇的に変える中で、人間の役割、特に「終わり」を意識した意思決定の重要性がこれまで以上に高まっていることを示す記事だ。