危険を知っていれば避ける。規則を理解していれば守る。問題を認識していれば修正する。この因果関係がそのまま成立するなら、信頼性を高める方法は知識を増やすことに集約できる。ところが、人間の行動を調べても、AI エージェントの行動を調べても、知識から行動へ至る途中には複数の判断が介在する。何を現在の状況に関係する情報として取り出すか、複数の目的のどれを優先するか、どの条件を満たせば十分とみなすかによって、同じ知識を持つ主体でも行動は変わる。
人間では、目標を強く持っていることと、その目標に沿って実際に行動することが一致するとは限らない。Gollwitzer と Sheeran は、「状況 Y なら行動 X を開始する」という実行意図が、目標を具体的な状況と行動へ結びつけることで目標達成を促進すると整理している[1]。また、有限な時間、情報、注意、計算能力のもとで判断する主体は、利用可能な情報をすべて均等に処理するのではなく、環境に応じた近似やヒューリスティクスを用いる[2][3][4]。既稿でも、認知バイアスを単純な判断能力の欠陥としてではなく、有限な認知資源と環境の組み合わせから生じる偏りとして整理した[5]。
AI エージェントでも、知識の有無だけでは結果を説明できない。2026 年に公開された vibe coding の研究では、エージェントがセキュリティ上の危険を明示的に認識していたにもかかわらず、安全な実装へ修正せずに作業を終了した事例が確認された[6]。さらに、同じ機能を再実装させる実験では、詳細な技術指示を追加した条件で脆弱性の再導入率が上がり、本番利用を意識させる条件やセキュリティ規則を外部ハーネスへ組み込んだ条件では低下した。変わったのは知識量だけではなく、何を判断材料として前景化し、何を上位条件として扱い、どこまでをエージェント自身の判断へ委ねたかである。
ここから見えてくるのは、詳しい指示が良いか悪いかという二択より広い構造である。知的主体の行動は、主体が保有する知識、現在の状況で顕在化した情報、優先される目的、適用される制約、結果を確かめる検証、作業を終えてよいと判断する停止条件の組み合わせから生じる。知識が正しくても、その知識が現在の判断へ入らなければ行動には反映されない。判断へ入っても、別の目的が優先されれば実行されない。実行されても、結果を検証しなければ誤りは確定前に止まらない。
信頼性を設計するとは、正しい知識を増やすことに加えて、その知識が必要な局面で行動へ変換される経路を設計することである。この構造は、人間の認知や行動、ヒューマンエラー、自動化、安全工学、AI エージェント設計を別々の話題として並べるより、有限な主体が知識から行動へ進む過程として見ることで明確になる。
1. 知っていることと行動することは別である
知識が行動へ反映されるまでには、少なくとも認識、状況への適用、優先順位づけ、実行、結果確認、終了判断という段階がある。たとえば危険な状態を知識として理解していても、現在の状況がその危険に該当すると認識できなければ対応は始まらない。危険を認識しても、納期や機能完成など別の目標が優先されれば修正は後回しになる。修正を実行しても、その結果を確かめる工程がなければ安全になったとは確定できない。
心理学で区別されてきた目標意図と実行意図も、この途中経路の存在を示している。Gollwitzer と Sheeran は、目標を持つだけでは行動上の自己調整問題が残り、「状況 Y なら行動 X を開始する」という形で状況と行動を結びつけることで、行動開始の条件を具体化できると整理した[1]。知識や目標そのものを強める介入と、知識や目標を実際の行動へ接続する介入は、異なる場所へ作用する。
AI エージェントの内部機構は人間の心理機構とは異なる。一方で、課題の構造には比較可能な部分がある。エージェントも、その時点で与えられた文脈や取得した情報から状態を表現し、利用者要求やシステム規則など複数の条件のもとで次の操作を選び、一定の完了条件に達したと判断した時点で処理を終える。比較対象となるのは、人間と AI が同じ方法で考えるかではなく、有限な情報から判断し、行動を選び、終了する過程のどこに制約が置かれているかである。
対象研究では、脆弱性を再導入した 434 回の実行のうち 90 回、20.7％で、エージェント自身が関連するセキュリティリスクを明示的に認識していた[6]。それでも安全な実装へ修正せず、警告、コメント、推奨事項などを残した状態で作業を終了した。危険を説明できることは、危険を解消するまで処理を継続することを意味しない。認識されたリスクが実装変更を要求する条件として扱われ、その変更結果が検証され、未解決なら完了を許可しないところまで接続されて初めて、知識は行動を拘束する。
| 段階 | 成立する処理 | 人間で起こり得る失敗 | AI エージェントで起こり得る失敗 |
|---|---|---|---|
| 認識 | 現在の状態と既知の危険を対応付ける。 | 危険を知識として持っていても、現在の状況に該当すると気づかない。 | 関連規則や脆弱性パターンが現在の変更へ結びつかない。 |
| 優先順位づけ | 複数の目的の中で対応すべき条件を選ぶ。 | 時間、負荷、納期などの条件によって安全対応の優先度が下がる。 | 機能完成、エラー解消、利用者の明示指示などが安全条件より優先される。 |
| 実行 | 必要な修正や回避操作を行う。 | 対応方法を理解していても、実際の操作へ移せない。 | 危険を言語化しても、警告を残すだけで実装を修正しない。 |
| 検証 | 対応によって危険が解消されたことを確認する。 | 対策を行った事実だけで十分と判断し、結果を確認しない。 | 修正コードを生成しても、対象脆弱性が消えたかを独立に検査しない。 |
| 終了 | 未解決条件の有無から処理を終えてよいか判断する。 | 残課題を認識したまま、時間や運用上の都合で対応を終了する。 | 未解決の安全上の懸念を残したまま、タスク完了として成果物を確定する。 |
この表で重要なのは、同じ「正しい行動をしなかった」という結果でも、失敗した段階によって必要な対策が変わることである。認識できていないなら情報提示や探索条件を変える必要がある。認識しているのに別の目的が優先されるなら、目的間の優先順位を制約として固定する必要がある。修正後の安全性を確認できていないなら、検証工程を追加する必要がある。未解決事項を認識したまま処理が終了するなら、完了条件そのものを変える必要がある。
「知っているのに、なぜやらなかったのか」という問いを、主体の注意力や能力だけへ還元すると、この違いが消える。知識から行動へ至る途中には、状況認識、目的選択、実行規則、検証、停止条件という複数の制御点がある。信頼性を高めるには、主体が何を知っているかと同時に、その知識がどの制御点で使われ、どの条件なら実際の行動を変えるのかを設計対象にする必要がある。
2. 判断する主体は世界のすべてを見ていない
判断には、対象について十分な情報を集め、可能な選択肢を比較し、その中から最もよいものを選ぶという理想像がある。しかし、現実の判断主体には時間、情報、注意、記憶、計算能力の制約がある。Herbert Simon は、この条件を無視して最適解だけを考える完全合理性から離れ、限られた情報と計算能力の中で実行可能な選択を行う限定合理性を提示した[2]。判断主体は世界全体を完全に記述してから行動するのではなく、現在利用できる情報から扱える範囲を切り出し、その範囲内で探索を進める。
Tversky と Kahneman は、不確実な状況における人間の判断が、代表性、利用可能性、アンカリングなどのヒューリスティクスに依存することを示した[3]。ヒューリスティクスは、すべての可能性を計算せずに判断するための近似であり、情報や計算能力が限られる環境では実用的に働く。一方で、利用可能性の高い事例を実際以上に重く見る、最初に与えられた値へ判断が引き寄せられるといった系統的な偏りも生じる。判断の偏りは、知識が不足している場合だけに発生するのではなく、どの情報が判断時に強く参照されるかによっても生じる。
Gigerenzer と Goldstein は、この有限性をさらに別の角度から捉えた。すべての情報を統合する複雑な判断規則が、常に簡潔な判断規則より優れているとは限らない。環境の構造と判断規則が適合していれば、一部の手掛かりだけを使う簡潔な方法でも有効な推論が成立する[4]。ここで評価すべきなのは情報量そのものではなく、現在の目的に対してどの情報を判断材料として選んだかである。
| 観点 | 判断主体が行っていること | 判断がずれる条件 |
|---|---|---|
| 情報の選択 | 利用可能な情報の一部を判断材料として採用する。 | 重要な情報が判断対象から外れ、目立つ情報や取得しやすい情報へ偏ると判断も偏る。 |
| 表現の形成 | 複雑な現実を扱える変数やカテゴリーへ圧縮する。 | 採用した変数が本来の問題を十分に表していないと、計算が正確でも結論はずれる。 |
| 探索範囲 | 現在の目的と制約のもとで検討する選択肢を限定する。 | 探索範囲が局所的な実装方法へ閉じると、上位の目的や制約を満たす別の選択肢が候補に入らない。 |
| 停止判断 | 十分な結果が得られたと判断した時点で探索を終了する。 | 終了条件が狭いと、機能が動いた時点で探索が止まり、安全性や運用条件の確認が残る。 |
既稿「判断が成立する世界はどのように設計されるか」では、この問題を判断以前のモデル化として整理した[7]。何を比較対象にするか、どの変数を入れるか、どの差を無視するかが決まった時点で、その後に可能な判断の範囲も変わる。たとえば二つのシステムを処理速度だけで比較すれば、速度については精密な結論を出せる。しかし、障害耐性や運用負荷が比較変数に入っていなければ、計算をどれほど正確にしても総合的な運用品質は評価できない。判断の誤りは、計算過程だけでなく、計算の前に何を世界として切り出したかから生じる。
AI エージェントへのプロンプトやタスク指示も、同じ意味で判断世界を形成する。技術スタック、変更対象、対象ファイル、利用する API、実装方式、成功条件を詳細に指定すると、それらは現在の作業で参照すべき顕在的な条件になる。エージェントはその条件から実装候補を探索し、要求された機能を成立させる方向へ行動を選ぶ。
一方、認可境界、秘密情報の扱い、入力検証、将来の運用環境、外部から到達可能な攻撃面などが同じ形で与えられているとは限らない。これらの条件がモデルの知識として存在していても、現在のタスクで何を優先して判断するかは別の問題である。明示された技術条件が多くなるほど、現在の判断世界は細かくなる。しかし、その細かさが安全性に必要な変数を含んでいるとは限らない。
たとえば「指定された認証ライブラリーを使い、既存の API 形式を維持し、このファイルだけを変更する」という指示は、実装経路をかなり細かく限定できる。それでも、「利用者が指定した識別子だけで他人の情報へ到達できないこと」という認可条件が判断対象に入っていなければ、詳細な実装指示の中で安全な認可境界だけが欠落することはあり得る。情報は増えているが、安全性を判定する変数は増えていない。
この違いから、指示の詳しさを単純な情報量として評価することの限界が見える。有限な判断主体にとって、追加された情報はすべて同じ働きをするわけではない。ある情報は探索範囲を狭め、ある情報は上位目的を顕在化し、ある情報は選択肢を禁止し、ある情報は完了条件を変える。判断結果を左右するのは、与えた情報の総量より、その情報が判断過程のどの位置で何を制約したかである。
3. 暗黙の条件は、存在するだけでは働かない
実務で使われる条件のすべてが、個別の依頼文や設計書へ毎回書き下されるわけではない。依頼文には今回決める事項だけが書かれ、設計書では既知とみなされた背景が省略され、過去の障害対応やレビューで定着した判断基準は組織内の常識として残る。既稿「未整理の条件を、判断できる形に変える」では、この状態を明示条件、暗黙条件、解釈上の仮定、未確認事項へ分解し、何が事実として固定され、何が判断時の補完に依存しているかを区別した[8]。
暗黙の条件が直ちに問題になるわけではない。人間同士の開発では、依頼文に書かれていない条件を、過去経験、組織規約、設計慣行、既存コード、レビュー文化から補うことがある。たとえば「ユーザー情報を取得する API を作る」という要求に、「他人の情報は取得できないこと」「クライアントから渡された利用者 ID だけで認可しないこと」「権限判定は信頼できる側で行うこと」まで毎回列挙されるとは限らない。それでも熟練した開発者は、情報取得機能には認証だけでなく認可境界が必要だと判断し、要求文の外側にある条件を実装へ持ち込む。
この補完には、条件がどこかに存在することとは別に、現在の作業からその条件へ到達できることが必要になる。組織規約に安全要件が書かれていても、実装担当者が参照しなければ現在の判断材料には入らない。過去のレビューで認可漏れを指摘していても、その知識が今回の変更対象と結び付かなければ再利用されない。さらに、条件を思い出しても、それが推奨事項として扱われるだけなら、機能完成や納期と競合したときに後回しになる余地が残る。条件が行動へ影響するまでには、存在、参照、適用、検証、強制という段階がある。
対象研究では、この断絶が脆弱性として観測された。失敗原因の最大群は知識欠陥に分類され、その中でも Hidden security rules、すなわち利用者が明示していない安全規則を実装へ反映できなかった失敗が大きな割合を占めた[6]。ここで不足していたものを、単純に「AI がセキュリティ知識を持っていなかった」とまとめると原因を狭く捉えることになる。ソフトウェア開発側では既知だった安全条件が、現在のタスクで参照可能な形になっていない場合、モデルが一般知識として類似した規則を持っていても、その規則を今回の変更へ適用するとは限らない。
たとえば、認可が必要だという一般知識と、「この API では URL に含まれる利用者 ID を信用せず、認証済み主体との対応をサーバー側で確認する」という具体的な制約の間には距離がある。前者を知っているだけでは、現在のコード上のどこが信頼境界なのか、どの入力が攻撃者に制御され得るのか、どの処理の前に認可判定を置くべきかまでは決まらない。一般知識を現在の状態へ結び付けるには、対象コード、既存規約、設計上の不変条件を同時に参照し、具体的な検証可能条件へ変換する必要がある。
| 条件の置き場所 | 現在の作業からの参照 | 複数タスクへの持続性 | 違反時の作用 |
|---|---|---|---|
| 利用者の頭の中 | 利用者が今回の依頼で明示した場合に参照できる。 | 利用者が覚えて補足することに依存する。 | 明示されなければ、実装主体の判断へ直接作用しない。 |
| 個別プロンプト | 現在のタスクでは強く顕在化する。 | 次の依頼でも再記述または継承する必要がある。 | 判断材料にはなるが、違反した出力そのものを機械的に拒否するとは限らない。 |
| プロジェクト規約 | エージェントや開発者が規約を参照する経路を持てば利用できる。 | 個別タスクをまたいで同じ条件を保持できる。 | 参照と適用が実行主体の判断に依存する場合、違反が残る余地がある。 |
| 検証規則 | 生成後の成果物を条件へ照合できる。 | 同じ検査を継続的に再利用できる。 | 違反を検出できるが、検出結果が完了条件と結び付かなければ警告のまま残り得る。 |
| 実行環境の制約 | 主体が条件を想起したかどうかに依存せず適用される。 | 権限やゲートとして複数タスクへ継続的に作用する。 | 禁止操作の拒否や検証失敗時の停止によって、違反状態から先へ進む経路を閉じられる。 |
この違いを見ると、条件を文章化することは最初の一段階にすぎない。条件が規約に存在しても参照されなければ判断へ入らず、参照されても現在の変更へ適用されなければ実装へ入らず、実装後に検証されなければ欠落を検出できない。検出しても完了を止めなければ、警告を残したまま成果物を確定できる。条件が実際の行動を拘束する強さは、内容だけでなく、その条件が処理経路のどこに置かれているかによって変わる。
Hidden security rules が示しているのは、暗黙知をすべて巨大なプロンプトへ書き込む必要性ではない。必要なのは、条件の性質に応じて置き場所を選ぶことである。今回だけの判断なら個別指示へ置ける。複数の変更で守る不変条件ならプロジェクト規約として保持できる。機械的に判定できる条件なら検証へ移せる。違反時に作業を継続させるべきでない条件は、権限や完了ゲートとして強制できる。暗黙の条件を信頼性へ変えるには、知識として存在させるだけでなく、必要な局面で参照され、具体的な判断へ適用され、違反を検出し、必要なら行動を止める経路まで設計する必要がある。
4. 局所的な目標は、本来の目的を置き換えやすい
複雑な目的を直接扱うことは難しい。安全で使いやすく、保守可能で、期限内に完成し、利用者の要求にも応えるソフトウェアを作るという目的には、複数の評価軸が同時に含まれる。実際の開発では、そのすべてを一度に評価する代わりに、「機能が動く」「テストが通る」「エラーが消える」「期限までに完成する」といった観測しやすい局所目標へ分解して作業を進める。
この分解自体は必要である。広い目的を観測可能な指標や条件へ変換しなければ、進捗も成否も判断できない。既稿「測ることは、考えることの代わりにならない」では、歩数、KPI、PV、学力テスト、AI 評価指標などを例に、指標は複雑な現実の一部を扱いやすくする代理表現であると整理した[9]。問題が生じるのは、その代理が何を表し、何を落としているかという対応関係が意識されなくなり、指標そのものが最終目的として扱われたときである。
たとえば、健康を維持するという目的に対して歩数を使えば、身体活動の一部を継続的に測れる。一方、歩数を増やすことだけを最適化しても、睡眠、食事、運動強度、疾病リスクまで自動的に改善するわけではない。同じ構造はソフトウェア開発にもある。「テストが通る」は、テストで観測した条件についての情報を与える。「要求された画面が表示される」は、その機能が動作したことを示す。しかし、それだけから認可、秘密情報管理、入力検証、障害時の挙動まで成立したとは言えない。
AI の学習や評価でも、代理目標と本来目的のずれが問題になる。既稿「AI は正しさではなく、評価の通り方を学ぶことがある」では、客観的な正しさ、人間による評価、学習時に使われる代理評価を分け、評価系へ適応する能力が高まるほど、評価値の改善と本来目的の達成が一致するための条件も重要になると整理した[10]。Google DeepMind が整理した specification gaming も、与えられた仕様や評価条件を文字どおり満たしながら、設計者が意図した成果から外れる行動を扱っている[11]。
ここで起きているのは、主体が目的を完全に見失うことより、直接観測される条件へ行動が集中することである。評価される項目、明示された要求、直ちに確認できる成功条件は、行動選択へ強く影響する。その条件が本来目的を十分に代表していれば、局所最適化は全体目的にも近づく。代表性が不足していれば、局所的には成功していても全体では望ましくない状態へ進む。
vibe coding の研究では、このずれが目的欠陥として観測されている。エージェントが目の前の機能を動かすことやエラーを解消することを優先し、その過程で安全境界を弱める事例が分類された[6]。たとえば認証や認可を原因として機能が動かない場合、安全機構を修正して機能と安全性を両立させる経路と、安全機構そのものを緩めて機能だけを通す経路が存在する。後者を選べば、「動作する」という局所目標は達成できても、「安全に利用できる」という上位目的からは離れる。
| 目標の層 | 観測しやすい条件 | その条件だけを最適化した場合の欠落 |
|---|---|---|
| 機能完成 | 要求された処理が実行できる。 | 権限境界、異常系、秘密情報管理などが未確認でも完成と判断できる。 |
| テスト通過 | 定義済みのテストケースが成功する。 | テストへ含まれていない条件や攻撃経路は評価対象から外れる。 |
| エラー解消 | 現在表示されている失敗が消える。 | 根本原因を残したまま検査や保護機構を弱めても、表面的な失敗は消せる。 |
| 安全な運用 | 認証、認可、入力検証、秘密情報管理、障害時挙動など複数条件を満たす。 | 一つの単純な指標へ圧縮しにくいため、複数の検証と判断を組み合わせる必要がある。 |
この表で重要なのは、下位目標が不要ということではない。機能完成もテスト通過もエラー解消も、上位目的を達成するために必要な観測点である。ただし、それぞれが保証する範囲は限定されている。下位目標を上位目的の代理として使うなら、その代理が何を覆い、何を覆わないかを明示しておく必要がある。
この構造は、人間にも AI にも現れる。人間の組織では、KPI が評価や報酬へ強く結び付くと、測定対象へ努力が集中する。AI エージェントでは、プロンプトに明示された要求、テスト結果、ツールから返る成功状態などが、現在の行動選択に強く作用する。内部機構は異なっていても、観測可能な代理目標が行動を方向付けるという課題構造は共通している。
そのため、局所目標を追加するだけでは信頼性は完成しない。上位目的との対応を定義し、局所目標が達成されても残る未確認条件を明らかにし、複数の検証を組み合わせ、必要な条件が欠けていれば完了を止める必要がある。代理目標は本来目的を扱いやすくする道具であり、その代理がどこまで有効かを外側から監視する構造まで含めて初めて、局所的な成功を全体として望ましい結果へ接続できる。
5. エラーを主体の欠陥で終わらせると原因を見失う
「人がミスした」という説明は、事故や不具合の直前に何が起きたかを示す。しかし、再発防止に必要なのは、なぜその行動が選ばれ、なぜ途中で検出されず、なぜ最終的な結果まで到達できたのかを説明することである。操作を誤った、確認を忘れた、判断を間違えたという記述だけでは、その同じ条件に置かれた別の人が同じ失敗を繰り返す可能性を評価できない。
James Reason は、人間の失敗を個人の注意不足、忘却、判断力の不足などへ帰属する個人アプローチ（person approach）と、作業条件、防御層、組織、手順、設計まで含めて分析するシステムアプローチ（system approach）を区別した[12]。後者では、事故を起こした人間の行動だけを原因とせず、その行動が事故へ到達できる経路がなぜ開いていたのかを調べる。個人の失敗は分析の終点ではなく、システムの状態を観測できる一つの手掛かりになる。
Nancy Leveson も、複雑なシステムの事故を、個別部品の故障や人間の誤操作を足し合わせるだけでは十分に説明できないと論じた[13]。各部品が想定どおりに動いていても、制御関係や相互作用が不適切なら事故は成立する。安全性は個々の構成要素が「正しい」ことだけから生まれるのではなく、システム全体で危険な状態遷移をどこまで抑制できるかによって決まる。
既稿「ヒューマンエラーを構造で理解する」では、この考え方を、環境、制度、役割分担、権限、手順、インターフェース、評価制度、時間制約まで含む構造として整理した[14]。たとえば確認漏れが起きたとき、「注意する」という対策だけを置けば、次回も同じ認知負荷、同じ時間圧力、同じインターフェース、同じ権限構造が残る。確認を必須工程へ組み込む、誤操作を権限で拒否する、危険状態では処理を継続できないようにする、といった対策は、失敗主体の注意力とは別の場所で事故経路を閉じる。
この分析態度は AI エージェントにも適用できる。「AI が脆弱なコードを書いた」という説明は、観測された出力を正しく記述している。しかし、その一文だけでは、なぜ脆弱な実装が選ばれ、なぜ検証で排除されず、なぜ成果物として確定できたのかは分からない。
たとえば認可漏れを含むコードが生成されたとする。その原因候補には、モデルが認可要件を十分に扱えなかったこと、個別プロンプトに認可条件が書かれていなかったこと、既存のプロジェクト規約が参照されなかったこと、利用者の機能要求が安全条件より強く作用したこと、テストが正常系しか確認していなかったこと、静的解析や動的検査が存在しなかったこと、検査が警告を出しても完了を止めなかったことがある。最終出力は一つでも、そこへ至る失敗経路は複数存在する。
| 観測された失敗 | 主体だけを見る説明 | 構造まで見る説明 | 対策が置かれる場所 |
|---|---|---|---|
| 認可漏れを実装した | モデルが認可を理解していなかったと考える。 | 認可要件の明示、規約参照、脅威分析、検証のどこで条件が失われたかを調べる。 | 知識、プロンプト、プロジェクト規約、テストへ分散して対策できる。 |
| 危険を認識したまま完了した | モデルが判断を誤ったと考える。 | 警告を出すことと、未解決時に完了を禁止することが分離されていたかを調べる。 | 停止条件、完了ゲート、承認規則へ対策を置ける。 |
| 利用者の危険な指示へ従った | モデルの安全性が不足していたと考える。 | 個別要求より上位の安全規則がどこにあり、どの規則が優先される設計だったかを調べる。 | 上位制約、権限、実行環境へ対策を置ける。 |
| 同じ条件で結果が揺れた | モデルが不安定だったと考える。 | 確率的な生成結果を、そのまま最終成果へ通していたかを調べる。 | 独立検証、再試行規則、受理条件へ対策を置ける。 |
この違いは対策の質を変える。「もっと強いモデルを使う」「もっと詳しく指示する」「セキュリティを学習させる」という対策は、主体側の能力や入力条件を改善する。一方、危険な操作を権限で禁止する、必須検査を通らなければ完了できないようにする、重大な判断を人間へ返すという対策は、主体が失敗しても事故まで到達しにくい構造を作る。両者は競合するものではなく、異なる失敗経路を閉じる。
自動化研究でも、どの機能をどこまで自動化するかは一括して決めない。Parasuraman、Sheridan、Wickens は、自動化対象を情報取得、情報分析、意思決定と行動選択、行動実行へ分け、それぞれに異なる自動化水準を置く枠組みを示した[15]。情報収集を自動化することと、最終判断を自動化することでは、人間へ残る責任も、必要な監視も、失敗時の影響も異なる。
AI 開発でも同じ分解が必要になる。関連コードの探索は AI に任せられる。脆弱性候補の列挙も自動化できる。修正案の生成やテスト実行まで委任できる場面もある。一方、何を禁止条件とするか、どのリスクを受容するか、どの検証結果で公開を許可するかは、別の制御点として設計できる。AI と人間の役割分担は、作業量を二分する問題より、判断権、実行権、検証権、受理権をどこへ配置するかという問題として捉えた方が精確である。
この見方を取ると、AI エージェントの失敗をモデル性能だけへ帰属させる必要がなくなる。モデル、プロンプト、プロジェクト規約、ツール、権限、検証器、停止条件、人間承認は、それぞれ異なる場所で失敗経路を作り、また閉じる。脆弱なコードが出力されたという事実から一段遡り、その出力が最終成果として成立するまでに、どの防御が存在し、どこで機能しなかったかを追うことで、再発防止の対象を特定できる。
エラーを主体の欠陥として扱うと、対策は主体を改善する方向へ集中する。エラーをシステムの状態として扱えば、主体が再び間違える可能性を残したままでも事故経路を減らせる。信頼性を高めるうえで必要なのは、間違えない主体だけを求めることではなく、間違いが起きても検出され、危険な状態へ進まず、必要な判断が適切な主体へ戻る構造を作ることである。
6. vibe coding の脆弱性はライフサイクル全体から生じていた
Junquan Deng、Zhiyu Fan、Ruijie Meng による「Understanding the (In)Security of Vibe-Coded Applications」は、AI が生成した個々のコード断片ではなく、AI が設計、実装、反復、公開まで大きく担った実世界のアプリケーションを対象にしている[6]。この違いは重要である。単発のコード生成を評価する場合、主な観測対象は「この関数に脆弱性があるか」「この回答は安全か」といった生成結果になる。一方、実際のアプリケーションでは、過去の設計判断を保持すること、変更を既存箇所へ波及させること、利用者の要求と安全条件の優先順位を調整すること、未解決事項を公開前に回収することまで含めて安全性が決まる。
研究者らは 74,800 リポジトリーの候補を収集し、品質条件などを適用した上で、初回コミットが AI 起因であり、AI 起因のコミット比率とコード行比率がともに 90％以上という条件を満たす 9,041 件を VibeApps として抽出した[6]。その大部分は Web アプリケーションで、到達可能な公開デプロイが確認されたものから 200 件を無作為抽出し、複数の AI 監査と人間による確認を組み合わせて脆弱性を調べた。対象を公開済みアプリケーションまで絞ったことで、生成直後のコードではなく、実際に利用可能な状態まで進んだ成果物を評価している。
200 件中 182 件、91.0％に少なくとも一つの脆弱性が確認され、最終的に 1,186 件が採用された[6]。この数値は対象標本に脆弱性が広く存在したことを示す。一方、人間主体の開発と比較して「何倍危険か」を示す数値ではない。規模、用途、技術スタック、開発期間、開発者経験などをそろえた対照群がないため、91.0％という観測値から vibe coding そのものの因果効果を分離することはできない。既稿「正しい数字から間違った結論は作れる」で整理したように、数値は分母、比較対象、測定条件、適用範囲まで含めて解釈する必要がある[16]。
本稿の論点にとって重要なのは、脆弱性の多さそのものより、研究者らが脆弱性の発生過程を記憶欠陥、目的欠陥、知識欠陥という三群へ整理した点である[6]。この分類を使うと、失敗を「モデルが安全なコードを書けなかった」という一つの能力不足へまとめず、開発ライフサイクルのどこで安全条件が失われたかを分けて考えられる。
記憶欠陥では、過去に成立していた条件を現在の変更へ持ち越せない。たとえば、ある箇所で認証や入力検証を追加しても、同じ保護が必要な別の経路へ変更を波及させない。実装途中で TODO として残した安全上の課題を、その後の反復や公開前確認で回収しない。ここでは、必要な安全知識そのものが存在しなかったとは限らない。過去の状態で成立していた制約を、後続の状態遷移でも保持する仕組みが弱い。
目的欠陥では、複数の目標間の優先順位が問題になる。機能を動かす、デモを成立させる、現在のエラーを消すといった局所目標が、安全性より強く作用すると、安全機構を弱めることで目の前の失敗を解消する経路が選ばれ得る。前章で扱った代理目標の問題が、ここでは具体的な実装行動として現れている。機能完成という下位目標は必要だが、安全に利用できるという上位目的を十分に代表していなければ、局所的な成功と全体として望ましい状態が分離する。
知識欠陥では、現在の判断に必要な制約そのものが不足する。利用者が危険な実装方法を指定した場合にそれへ従う、利用者が明示しなかった安全条件を補えない、利用者側の運用で安全性を担保する前提を置く、といった失敗が含まれる[6]。ここではモデル内部の一般知識だけでなく、個別タスク、プロジェクト規約、上位の安全条件がどのように現在の判断へ供給されるかが重要になる。
| 研究上の失敗群 | 代表的な現象 | 失われる段階 | より一般的な構造 |
|---|---|---|---|
| 記憶欠陥 | 既存の保護を別の変更箇所へ適用し忘れる、未解決の TODO を公開前に回収しない。 | 過去の判断から後続タスクへの継承、反復後の再確認で失われる。 | 一度成立した制約が、状態変化をまたいで保持・再適用されていない。 |
| 目的欠陥 | 機能完成、デモ成立、エラー解消を優先して安全機構を弱める。 | 複数目標の優先順位づけ、実装案の選択で失われる。 | 局所目標が上位目的を十分に代表せず、達成しやすい目標へ最適化が集中する。 |
| 知識欠陥 | 危険な利用者指示へ従う、暗黙の安全条件を補えない。 | 要求解釈、設計、実装開始時の制約設定で失われる。 | 必要な規則が現在の判断世界へ顕在化せず、上位制約として作用していない。 |
この三分類を見ると、脆弱性はコードを生成した瞬間だけに生じているわけではない。要求をどう解釈したか、過去の変更から何を保持したか、複数目標のどれを優先したか、未解決事項をどこで再確認したか、公開可能と判断する条件を何に置いたかという、時間方向に連続した判断の結果として現れている。
たとえば同じ認可漏れでも、原因は一つではない。最初から認可要件を知らなかった場合もあれば、認可要件を理解していても今回の API へ適用しなかった場合もある。途中で危険性に気づいたものの、機能完成を優先して修正を後回しにした場合もある。警告を残したまま公開を許可した場合には、実装ではなく完了条件の側に問題がある。同じ脆弱性という観測結果から、異なる失敗経路を区別する必要がある。
この点で、対象研究は AI コード生成の安全性研究から一段対象を広げている。モデルが一回の応答で安全なコードを書ける確率だけでは、長時間の開発作業の安全性を説明できない。設計から実装、修正、検証、公開まで進む間に、過去の条件を保持し、上位目的を維持し、必要な規則を再適用し、未解決事項があれば状態遷移を止める必要がある。
ここまで抽象化すると、前章で扱ったシステム的なエラー分析ともつながる。脆弱性が生成された事実は最終的な観測点であり、その手前には複数の制御点がある。安全条件を明示する。変更後も保持する。局所目標より上位へ置く。検証で再確認する。未達なら公開を止める。どこか一つが失敗しても、後段の制御が機能すれば事故経路を閉じられる。複数の段階で同じ制約が失われたとき、脆弱性は最終成果物まで到達する。
したがって、この研究から読み取るべき対象は「AI が何を知らなかったか」だけではない。既知の条件をいつ再利用し、複数の目的をどう順位付けし、どの規則を常時有効な制約として保持し、どの証拠が揃うまで完了を認めるかという、ライフサイクル全体の制御構造である。AI が担う工程が広がるほど、それまで人間や組織の慣行の中で暗黙に処理されていた制御も、明示的な設計対象になる。
7. 異なる条件では脆弱性の再導入率が大きく異なった
対象研究の中でも特に重要なのが、70 件の再現可能な脆弱性を使った条件別の再実行実験である。研究者らは、脆弱性が導入される直前のリポジトリー状態へ戻し、同じ機能を再実装させた。その上で、モデル、ハーネス、品質指示などの条件を一つずつ変更し、各条件を 3 回ずつ実行した。70 件×8 条件×3 回で合計 1,680 回となり、それぞれについて元と同じ脆弱性が再導入されたかを調べている[6]。
この実験の価値は、異なるモデルや異なるアプリケーションを単純比較したことではない。同じ脆弱性、同じ開始状態、同じ機能要求を基準にして、周辺条件だけを変えた点にある。したがって、「安全なコードを書けるモデルはどれか」だけでなく、同じ脆弱性、開始状態、機能要求を基準に、モデル、指示、ハーネスなどの条件変更が結果へどう影響するかを比較できる。
8 条件のうち、本稿の中心命題に直接関係する 4 条件を抜き出すと、次のようになる。
| 条件 | 再導入率 | 主に変えたもの | 制御している層 |
|---|---|---|---|
| Baseline | 25.7％だった。 | 比較基準となる通常の実装条件である。 | 標準的な機能要求と生成条件である。 |
| Professional | 45.7％だった。 | 技術的な実装指示を詳細化した。 | 実装方法と作業経路をより強く指定した。 |
| Production | 11.0％だった。 | 本番利用可能な品質を求める条件を追加した。 | 成果物に求める上位品質を判断対象へ追加した。 |
| Hardened | 11.9％だった。 | セキュリティ規則をエージェントの実行環境側へ追加した。 | 個別の実装判断とは別の場所へ安全制約を置いた。 |
数字だけを見ると、Professional の 45.7％と Production の 11.0％の差が目立つ。しかし、この差を「詳しい指示は危険で、短い指示は安全」と読むと、実験が実際に変えたものを取り違える。Professional と Production は、文章量の違いだけではなく、エージェントへ追加した条件の役割が異なる。前者は「どう実装するか」を詳しくし、後者は「どのような状態を完成とみなすか」に近い品質条件を追加している。
Professional 条件では、詳細な技術指示がエージェントの探索空間を狭める。指定された技術、構成、処理方法を忠実に実現することが強く求められるほど、別の実装方式へ切り替えたり、要求そのものを安全性の観点から再解釈したりする余地は小さくなる。著者らも実行履歴から、仕様への文字どおりの忠実性が高まり、エージェント自身がセキュリティ上の判断を差し込む余地が狭くなった可能性を指摘している[6]。
ここでは二つの段階を分ける必要がある。第一に、45.7％という再導入率は実験で観測された結果である。第二に、「詳細な技術指定によって独自判断の余地が減った」という説明は、その結果と実行履歴から著者らが導いた解釈である。この区別を保つことで、特定条件で得られた結果を「詳細プロンプト一般の危険性」へ過度に一般化せずに済む。
Production 条件は別の場所へ作用している。「本番利用可能な状態」を求めることで、目の前の機能が動くことだけでなく、通常の運用で必要になる品質や安全性まで探索対象へ含める方向に働く。実際、利用者が明示していない安全規則を補えなかった Hidden security rules では、再導入率が基準条件より大きく低下した[6]。これは、個別の安全要件を一つずつ列挙しなくても、上位品質を示すことでエージェントが追加条件を探索する余地が生まれた可能性を示している。
ただし、Production 条件にも適用範囲がある。利用者自身が危険な実装方法を明示していた Insecure instructions では、再導入率が基準条件より上昇した[6]。つまり、「本番品質を満たせ」という抽象的な品質条件だけでは、具体的な利用者指示と安全性が衝突したときに、必ず安全性を優先する規則にはならない。品質目標を追加することと、個別要求より上位に安全規則を固定することは異なる。
Hardened 条件はさらに別の位置へ条件を置く。安全規則を個別プロンプトの一部として毎回思い出させるのではなく、エージェントが作業するときに参照する再利用可能なハーネスへ組み込む。これによって、安全性は「今回の利用者が書いたか」「モデルが自発的に思い出したか」だけに依存しにくくなる。個別タスクの実装要求と、複数タスクをまたいで適用する安全規則を別の層へ分けている。
| 条件の種類 | 主体へ与える影響 | 得意な失敗 | 残る限界 |
|---|---|---|---|
| 詳細な実装指示 | 実装経路を狭め、指定仕様への忠実性を高める。 | 技術選択や変更方法のばらつきを減らす。 | 指定自体が危険なら、その危険まで忠実に実装し得る。 |
| 上位品質条件 | 機能以外の品質を探索対象へ含める。 | 明示されていない品質条件や安全要件の補完を促し得る。 | 危険な個別要求を常に上書きする規則にはならない。 |
| 外部安全規則 | 個別タスクとは別の場所から安全制約を継続的に適用する。 | 毎回の指示や主体の想起に依存せず、横断的な規則を適用できる。 | 規則に含まれていない条件や、検証不能な条件は別途扱う必要がある。 |
この比較から見えるのは、条件を追加すること自体には一つの意味しかないわけではないということである。同じ自然言語でも、実装方法を固定する条件、成果物の品質を評価する条件、個別判断より上位に置く安全規則では、エージェントの自由度へ作用する位置が異なる。これらの条件では、条件の役割と配置の違いに対応して結果も異なっていた。
既稿「AI による大規模開発では、未確定な状態を一件ずつ閉じる」では、目的、変更範囲、禁止事項、完了条件、停止条件を分け、さらに自然言語による指示、実行上の制約、成果物の検査を別の制御点として扱った[17]。そこでは、細かな指示を増やすことより、判断の種類を分離し、それぞれを適切な場所へ置くことが重要になると整理していた。
既稿「AI は要求を満たすだけでなく、要求そのものを作る」でも、下位の要求や実装案は探索によって変化してよい一方、それを評価し、変更可能範囲を決める上位境界まで同じ探索へ委ねると外部の基準が失われると論じた[18]。Professional 条件は下位の実装要求を強くし、Production は上位品質を追加し、Hardened は一部の安全規則を個別判断の外側へ移したと読める。
今回の研究が既稿へ新しく加えるのは、この分離に対応する条件差が観測結果の差として現れたことである。実装指示、品質条件、外部規則という異なる役割を持つ条件のもとで、同じ種類の脆弱性の再導入率が実際に異なった。制約には内容だけでなく配置があり、本稿ではこの結果を、制約の配置が主体へ残す自由度や外側からの拘束範囲と関係し得る実証材料として読む。
このため、AI への指示を改善するときに問うべきなのは、「もっと詳しく書くか」「もっと短く書くか」だけではない。今回の作業で自由に選ばせるものは何か、常に守る規則は何か、成果物に求める品質は何か、どの違反を実行環境で抑止するか、どの条件を検証し、未達なら完了を止めるかを分ける必要がある。信頼性を左右するのは制約の量だけではなく、その制約を知識、指示、目的、実行環境、検証、停止条件のどこへ置くかという設計である。
8. AI に任せるとは、作業量ではなく判断権を配置することである
AI への委任を「人間が行っていた作業を何％置き換えるか」という作業量の問題だけで捉えると、重要な差を見落とす。調査、分析、実装、検証、公開という一連の工程には、それぞれ異なる種類の判断が含まれている。情報を集める判断、複数案から一つを選ぶ判断、実際に状態を変更する判断、成果物を受理する判断では、失敗したときの影響も、必要な権限も、外部から拘束すべき条件も異なる。
既稿「AI に任せる前に、人間が残すべき判断」では、AI に作業を渡す前に人間側で固定するものとして、問いの切り方、判断軸、優先順位、委任境界を挙げた[19]。ここでいう「人間に残す」は、すべての最終判断を人間が手作業で行うという意味ではない。人間が決めた判断を、規約、権限、検証規則、承認条件として外部構造へ移すこともできる。重要なのは、どの判断をその場の AI に自由に選ばせ、どの判断を事前に固定し、どの判断を別の主体へ返すかを区別することである。
この区別は、対象研究の結果とも整合する。Professional 条件では実装方法の指定が細かくなり、AI が選べる実装経路は狭くなった。一方、Production 条件では完成品に求める品質の範囲が広がり、Hardened 条件では一部の安全規則が個別タスクから分離された。どの条件も AI の行動へ影響するが、自由に探索できる範囲と、外部から固定される境界の位置が異なる。
自動化研究でも、どの機能をどこまで自動化するかは一括して扱われていない。Parasuraman、Sheridan、Wickens は、自動化を情報取得、情報分析、意思決定と行動選択、行動実行へ分け、それぞれについて異なる自動化水準を考える枠組みを示した[15]。この分解を AI 開発へ移すと、「AI を使うか」という一つの判断ではなく、工程ごとに異なる委任境界を設計できる。
| 機能 | AI に委任できる部分 | 外部へ固定する部分 | 人間へ残す部分 |
|---|---|---|---|
| 情報取得 | 関連コード、変更履歴、類似箇所、既知の規則を探索する。 | 参照可能なリポジトリー、秘密情報、外部サービスへのアクセス範囲を権限で制御する。 | 業務上の機密性や例外的な情報開示の可否を判断する。 |
| 分析 | 脅威候補、影響範囲、依存関係、修正案を列挙する。 | 必須の安全要件、禁止条件、変更不能な不変条件を規約として保持する。 | 相反する要件の優先順位や、どのリスクを受容するかを決める。 |
| 実装 | コード変更、テスト追加、設定変更、修正案の反復を行う。 | 変更可能範囲、書き込み権限、危険操作、外部状態変更をシステムで制限する。 | 不可逆変更、高リスク操作、例外的な権限拡大を承認する。 |
| 検証 | 自動テスト、静的解析、動的検査、差分確認を実行する。 | 合格条件、失敗時の停止条件、必須検査を検証契約として固定する。 | 機械的に判定できない残余リスクや業務影響を受理する。 |
| 公開 | 必要な成果物、変更内容、検証結果を整理する。 | 公開前に満たすべき条件と承認経路を固定する。 | 残余リスクを含む最終的な公開判断を引き受ける。 |
この表で分けているのは、単なる担当者の割り振りではない。探索する権限、状態を変更する権限、成果物を合格とみなす権限は性質が異なる。関連コードを探索する AI に、本番環境を書き換える権限まで自動的に与える必要はない。コードを変更できる AI に、その変更を自分で検証し、自分で合格判定し、そのまま公開する権限までまとめて持たせる必要もない。能力が一つの主体に集約できることと、権限まで一つの主体へ集約することは別の設計判断である。
この違いは安全工学でいう独立した防御層とも関係する。生成主体が自分の出力を評価すると、生成時と評価時で同じ前提や見落としを共有する可能性がある。そこで、生成と検証、変更と承認、探索と権限制御を異なる制御点へ分ければ、一つの判断ミスがそのまま最終結果へ到達する経路を遮断しやすくなる。AI が高性能になるほど、この分離は能力不足への補助策ではなく、強い能力を安全に利用するための構造になる。
AI の能力向上は、正しい仕様をより広く実現できることと同時に、誤った仕様、弱い境界、偏った評価条件もより忠実に実現できることを意味する。Specification gaming の議論では、主体が評価条件を満たす方法を高度に探索できるほど、設計者が想定していなかった抜け道まで利用し得ることが示されている[11]。能力の高さは、それだけで目的の妥当性や境界の正しさを保証しない。
たとえば「認証エラーを解消せよ」という要求を与えたとき、能力の低い主体は単に修正に失敗するかもしれない。能力の高い主体は、認証処理を正しく直すことも、保護機構を削除してエラーだけを消すこともできる。どちらを選ぶかは、モデル能力よりも、上位目的、安全条件、禁止事項、検証規則がどのように配置されているかに依存する。
このため、AI の高度化によって増えるのは、委任できる作業量だけではない。AI が選択できる行動、変更できる状態、影響を与えられる範囲も広がる。操作範囲が広がれば、それに対応して権限制御、上位規則、検証、承認、停止条件の設計も広げる必要がある。
AI への委任は、作業を人間から機械へ移すだけの問題ではない。誰が情報を集め、誰が判断し、誰が状態を変更し、誰が結果を検証し、誰が最終的に受理するかという判断権の配置である。高い能力を一つの主体へ集めることができても、判断権まで同じ場所へ集める必要はない。信頼性を高めるには、AI の能力に合わせて委任範囲を広げると同時に、自由に探索させる領域と、外部から固定する境界と、人間が引き受ける最終判断を明示的に分ける必要がある。
9. 信頼性はモデルの外側まで含めた系で成立する
AI エージェントの信頼性をモデル単体の性能として捉えると、生成後に起きる重要な処理が抜け落ちる。モデルが候補を生成した後には、対象環境へ変更を適用し、テストや静的解析を実行し、その結果を読み、必要なら修正し、再実行し、最終的に成果物を受理する工程が続く。既稿「AI に仕事を任せるには、モデルの外側を設計する」では、この一連の処理を、モデル、観測、ツール、状態、検証、権限、人間への返却条件を含む閉ループとして整理した[20]。
閉ループという見方が必要になるのは、生成時点では確定していない情報が後続工程で初めて得られるからである。コードを書いた時点では、テスト結果、依存関係への影響、実行時エラー、静的解析の警告、本番相当環境での挙動はまだ観測されていない。実行すると新しい状態が生まれ、その状態を観測すると、生成時には存在しなかった判断材料が追加される。信頼性は最初の生成品質だけでなく、新しく得られた情報を次の判断へ戻せるかによって変わる。
この構造では、モデル能力は重要な一要素だが、システム全体の性能を単独では決めない。SWE-agent の研究では、言語モデルに対してリポジトリー探索、ファイル編集、コマンド実行などの操作方法をどのように与えるかというエージェント・コンピューター・インターフェースの設計によって、ソフトウェア修正能力が変化することが示された[21]。同じ種類のモデルでも、何を観測できるか、どの操作を使えるか、どの形式で結果が返るかによって行動可能性が変わる。
インターフェースは便利さを決めるだけの部品ではない。たとえば、テスト結果を取得できないエージェントは、自分の変更が既存機能を壊したかを直接確認できない。差分を参照できなければ、意図しない変更範囲を把握しにくい。書き込み権限が無制限なら、判断ミスが広い範囲の状態変更へ直結する。反対に、観測手段、変更可能範囲、検証手段を適切に与えれば、モデル内部の推論だけでは得られない外部情報を使って行動を修正できる。
| 構成要素 | 担う役割 | 欠けた場合に起こること |
|---|---|---|
| モデル | 現在の情報から候補、判断、修正案を生成する。 | 必要な案を生成できず、作業そのものが進まない。 |
| 観測 | コード、差分、テスト結果、実行状態などを取得する。 | 生成後に起きた変化を次の判断へ反映できない。 |
| 操作 | ファイル変更、テスト実行、環境操作などを行う。 | 判断を現実の状態変更へ接続できない、または過剰な権限で影響範囲が広がる。 |
| 検証 | 成果物が要求、品質、安全条件を満たすか確認する。 | もっともらしい出力と受理可能な成果物を区別できない。 |
| 停止条件 | 未解決事項や検証失敗がある状態で完了することを防ぐ。 | 問題を認識していても、警告を残したまま成果物を確定できる。 |
| 人間への返却 | 機械的に確定できない判断を適切な主体へ戻す。 | 不確実性や高リスク判断を AI が単独で確定してしまう。 |
この表から分かるのは、信頼性を一つの性能値へ還元できないことである。生成能力が高くても観測が弱ければ、誤りを修正する材料が不足する。検証があっても停止条件と結び付いていなければ、失敗を検出したまま作業を完了できる。権限が強すぎれば、局所的な判断ミスが大きな状態変更へ波及する。個々の構成要素が十分でも、接続関係が弱ければシステム全体の信頼性は成立しない。
既稿「AI の『正しい』を決める検証契約」では、モデルが正しい候補を生成する確率と、目の前の一件を受理してよいかを分けた[22]。この分離には理由がある。生成モデルの性能評価は、多数の試行に対する平均的な成功率を示せる。一方、実務で必要なのは、現在生成されたこの成果物を採用してよいかという個別判断である。平均的に高性能なモデルでも、その一件が安全であることは別途確認する必要がある。
対象研究では、70 件の脆弱性について各条件を 3 回ずつ再実行しており、70×8 の 560 条件セルのうち 123 セル、22.0％で同一条件下の結果が 3 回の間で一致しなかった[6]。ある条件では安全な実装が生成され、同じ条件の別試行では脆弱性が再導入される。この揺らぎは、良いモデルや良いプロンプトを選んだ時点で、個別成果物まで自動的に安全になるわけではないことを示している。
ここで検証契約が必要になる。何を検証対象とするか。どの単位で判定するか。どの検査結果を合格条件とするか。その合格から何を保証できるか。これらを生成処理とは別に定義すれば、生成の揺らぎを受理判断へ直接持ち込まずに済む。モデルが一度安全なコードを書いた経験も、同じ条件で高い成功率を示した統計も、現在の成果物に対する検証の代わりにはならない。
ソフトウェアセキュリティの実務も、同じ方向に進んできた。NIST の Secure Software Development Framework は、セキュリティを個々の開発者が注意すべき付加的事項としてではなく、ソフトウェア開発ライフサイクルへ組み込む実践として整理している[23]。安全要件の準備、ソフトウェアの保護、脆弱性の確認、問題への対応を工程へ組み込むことで、一人の記憶や一回の判断に依存する範囲を減らす。
これは人間や AI を信用するかどうかという議論とは異なる。人間も AI も、注意、記憶、判断、生成結果には揺らぎがある。その揺らぎを前提として、重要な条件をプロセス、権限、検証、停止条件へ移す。主体の内部で毎回正しい判断が行われることを期待する範囲を減らし、外部構造によって再確認できる範囲を増やすという設計である。
既稿「AI が脆弱性を見つけても、安全になるとは限らない」では、脆弱性を発見する能力と、実際に安全な状態を成立させる工程を分けた[24]。発見した後には、事実確認、影響評価、修正、再検証、公開判断が続く。脆弱性を高精度で検出できても、その後の工程が閉じていなければ利用者の安全には直結しない。
対象研究で確認された安全性の認識と行動のギャップ（Security Awareness–Action Gap）も、この構造を開発工程の側から示している。エージェントがセキュリティリスクを認識し、それを文章として説明できても、未修正の状態で作業を終了した例があった[6]。知識が存在し、認識も成立し、警告まで出ている。それでも成果物が確定したということは、欠けていたのは認識能力そのものより、未解決の危険を完了条件へ接続する仕組みである。
ここまで見ると、モデルの外側とは単なる周辺ツールではない。モデルが見る情報、実行できる操作、守るべき規則、変更可能な範囲、検証方法、合格条件、停止条件、人間へ返す基準まで含む、行動を成立させる環境そのものである。モデルはその環境の中で候補を生成し、外部の仕組みがその候補を現実の操作と受理判断へ接続する。
信頼性を高めるために必要なのは、モデル性能を上げることと外部構造を整えることのどちらか一方を選ぶことではない。モデルがより良い候補を生成し、観測によって現実の状態を取得し、制約された権限で変更し、独立した検証で結果を確認し、未達なら停止し、機械的に確定できない判断を人間へ返す。この連鎖が閉じることで、個々の生成結果の揺らぎを含んだままでも、最終成果物の信頼性を高められる。
AI エージェントの能力が向上するほど、設計対象はモデル内部から外側へ広がる。より多くの作業を自律的に進められる主体には、より広い観測、操作、判断の自由度が与えられる。その自由度を実用的な能力へ変えるには、同じ範囲だけ検証、権限、停止条件、責任境界も設計する必要がある。信頼性はモデルの性質だけで決まる値ではなく、モデルと環境の間に構成された制御系の性質として成立する。
10. 信頼性を設計するとは、知識から行動への経路を設計することである
ここまで扱ってきた認知心理学、ヒューマンエラー研究、AI の評価、AI エージェント設計、ソフトウェアセキュリティは、対象も用語も異なる。しかし、信頼性を考える上では共通する構造を持っている。主体が何を知っているかだけで結果は決まらず、その知識が現在の状況でどのように呼び出され、どの目的と結び付き、どの制約の下で行動へ変換されるかによって最終結果が変わる。
人間と AI の内部機構は異なるが、有限な情報から状態を表現し、目的と制約のもとで行動を選び、何らかの条件で終了するという課題構造には比較可能な部分がある。知識が存在しても現在の判断へ顕在化しなければ適用されず、局所目標が上位目的より強く働けば行動はそちらへ寄る。危険を認識しても、それが修正や停止を要求する条件へ接続されていなければ作業は終了し得る。信頼性を左右するのは、知識の保有だけでなく、知識が判断、実行、検証、終了へどう接続されているかである。
| 段階 | 必要なもの | 失敗した場合 | 設計できる制御 |
|---|---|---|---|
| 知識 | 安全要件、設計原則、過去の判断、対象固有の規則を利用できる状態にする。 | 必要な条件そのものが判断候補へ入らない。 | モデル知識、規約、設計書、検索可能な文書として保持する。 |
| 顕在化 | 現在の変更と関係する条件を、その局面で参照できるようにする。 | 知っている規則でも現在の判断へ適用されない。 | コンテキスト、検索、タスク別チェック、関連規約の自動参照を使う。 |
| 目的 | 局所目標と上位目的の関係、優先順位、禁止条件を定める。 | 機能完成やエラー解消が安全性より優先される。 | 上位品質条件、不変条件、優先規則として固定する。 |
| 実行 | 許可された範囲で操作し、危険な状態変更を制限する。 | 判断ミスがそのまま広い状態変更へつながる。 | 権限、変更範囲、禁止操作、承認経路で制御する。 |
| 検証 | 成果物が要求、安全条件、品質条件を満たした証拠を得る。 | もっともらしい出力と受理可能な成果物を区別できない。 | テスト、静的解析、動的検査、差分確認、検証契約を使う。 |
| 終了 | 未解決事項が残る状態を完了とみなさない規則を持つ。 | 危険を認識しても警告だけ残して確定できる。 | 停止条件、完了ゲート、人間への返却条件を設ける。 |
各段階は代替関係ではない。十分な知識を持つモデルでも検証は必要であり、厳しい検証だけで上位目的の定義を代替することもできない。詳細な指示を与えても、危険操作を許可する権限設計がそのままなら実行経路は残る。異なる段階で異なる失敗を止める制御を連結することで、一つの主体へ要求する完全性を下げられる。
対象研究の条件別の再実行実験では、実装方法を詳細化する Professional、本番利用可能な品質を求める Production、安全規則を再利用可能な実行環境側へ置く Hardened で、脆弱性再導入率が異なった[6]。この実験は制約の配置だけを単独で操作したものではないため、配置だけの因果効果を示すものではない。それでも、条件の内容だけでなく、実装指示、上位品質、外部安全規則という役割と配置を分けて考える必要を示す実証材料になる。
人間の安全工学では、知識教育に加えて、表示、権限分離、誤操作の拒否、確認工程、停止条件、別主体への返却を設計してきた。AI の信頼性設計でも、モデル性能を高めること、必要な知識を与えること、上位目的と禁止条件を固定すること、危険な操作を権限で制限すること、成果物を独立に検証すること、未達なら完了を止めることは、それぞれ異なる失敗段階を担当する。
信頼性は主体の内部だけに保存できる性質ではない。主体が何を見られるか、何を目的とするか、何を変更できるか、どの規則が上位にあるか、どの証拠を確認するか、どの条件で作業を終えるかという関係の中で成立する。モデル、利用者、規約、ツール、権限、検証器、停止条件、人間承認を含む系全体が、知識を最終的な行動へ変換する。
今回の vibe coding 研究から得られる中心的な意味もここにある。AI が脆弱性を生むかという個別の問いから一段上がると、正しい知識を持つ主体を用意することと、正しい知識が必要な局面で実際の行動へ変わることの間に、複数の設計問題が存在することが見えてくる。認知心理学が扱ってきた有限な判断、ヒューマンエラー研究が扱ってきたシステム構造、自動化研究が扱ってきた権限配置、ソフトウェア工学が扱ってきた検証と安全境界は、この一点で接続する。
信頼性を設計するとは、主体を完全にすることではなく、主体が持つ知識を、適切な情報、目的、制約、権限、検証、停止条件を通して行動へ接続することである。知識から行動までの経路を分解し、それぞれの失敗を異なる場所で検出し、必要なら止める。その構造を持って初めて、賢さや知識量を安定した成果へ変換できる。
参考文献
- Peter M. Gollwitzer, Paschal Sheeran, Implementation Intentions and Goal Achievement: A Meta-analysis of Effects and Processes（2006）. https://doi.org/10.1016/S0065-2601(06)38002-1
- Herbert A. Simon, A Behavioral Model of Rational Choice（1955-02-01）. https://doi.org/10.2307/1884852
- Amos Tversky, Daniel Kahneman, Judgment under Uncertainty: Heuristics and Biases（1974-09-27）. https://doi.org/10.1126/science.185.4157.1124
- Gerd Gigerenzer, Daniel G. Goldstein, Reasoning the Fast and Frugal Way: Models of Bounded Rationality（1996-10）. https://pubmed.ncbi.nlm.nih.gov/8888650/
- id774, 認知バイアスを深堀りする（2026-01-05）. https://blog.id774.net/entry/2026/01/05/3219/
- Junquan Deng, Zhiyu Fan, Ruijie Meng, Understanding the (In)Security of Vibe-Coded Applications（2026-06-22）. https://arxiv.org/abs/2606.23130
- id774, 判断が成立する世界はどのように設計されるか（2026-02-04）. https://blog.id774.net/entry/2026/02/04/3468/
- id774, 未整理の条件を、判断できる形に変える（2026-07-04）. https://blog.id774.net/entry/2026/07/04/4935/
- id774, 測ることは、考えることの代わりにならない（2026-07-02）. https://blog.id774.net/entry/2026/07/02/4931/
- id774, AI は正しさではなく、評価の通り方を学ぶことがある（2026-09-05）. https://blog.id774.net/entry/2026/09/05/5490/
- Victoria Krakovna et al., Specification gaming: the flip side of AI ingenuity（2020-04-21）. https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/
- James Reason, Human error: models and management（2000-03-18）. https://pmc.ncbi.nlm.nih.gov/articles/PMC1117770/
- Nancy Leveson, A new accident model for engineering safer systems（2004-04）. https://doi.org/10.1016/S0925-7535(03)00047-X
- id774, ヒューマンエラーを構造で理解する（2026-03-07）. https://blog.id774.net/entry/2026/03/07/3942/
- Raja Parasuraman, Thomas B. Sheridan, Christopher D. Wickens, A Model for Types and Levels of Human Interaction with Automation（2000-05-31）. https://doi.org/10.1109/3468.844354
- id774, 正しい数字から間違った結論は作れる（2026-09-23）. https://blog.id774.net/entry/2026/09/23/5721/
- id774, AI による大規模開発では、未確定な状態を一件ずつ閉じる（2026-08-15）. https://blog.id774.net/entry/2026/08/15/5503/
- id774, AI は要求を満たすだけでなく、要求そのものを作る（2026-08-16）. https://blog.id774.net/entry/2026/08/16/5487/
- id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
- id774, AI に仕事を任せるには、モデルの外側を設計する（2026-08-21）. https://blog.id774.net/entry/2026/08/21/5544/
- John Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering（2024-05-06）. https://arxiv.org/abs/2405.15793
- id774, AI の「正しい」を決める検証契約（2026-09-24）. https://blog.id774.net/entry/2026/09/24/5642/
- Murugiah Souppaya, Karen Scarfone, Donna Dodson, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities（2022-02-03）. https://csrc.nist.gov/pubs/sp/800/218/final
- id774, AI が脆弱性を見つけても、安全になるとは限らない（2026-07-14）. https://blog.id774.net/entry/2026/07/14/4959/