理想モデルの前提条件一覧

フェーズ2で整理した「理想像(To)」は、明示されないまま多くのことを前提にしています。このページは、その暗黙の前提条件を一覧化します。フェーズ3では、これらの前提が日本企業の現場で成立するかを1つずつ検証し、崩れる点をギャップとして扱います。

このページの鮮度について

技術の前提(A-T1〜A-T4)の成立度は、2026-08-06 時点の評価です。この分野は数か月で状況が変わるため、現在の到達点はエージェント型開発の現在地(基準日つき)を参照してください。個人・組織・知識の前提(P・O・K)は技術の進展では変わらないため、時点への依存は小さいと考えています。

前提の全体像: AIが解くのは一部だけ

理想像は「AIが実装を担えば全部解決する」かのように語られがちです。しかし前提を分解すると、AIが解くのは技術の前提だけで、個人・組織・知識の前提は人間の問題として残ります。ここが理想と現実のギャップの源泉です。

graph TD
  Ideal["理想像(To)の成立"]
  Ideal --> T["技術の前提<br>← AIが解く部分"]
  Ideal --> P["個人・スキルの前提<br>← 人間に残る"]
  Ideal --> O["組織・責任の前提<br>← 組織に残る"]
  Ideal --> K["情報・知識の前提<br>← 明文化コストが残る"]

前提条件の一覧

ノート

記号に A- を冠しているのは、移行段階 T-0〜T-4との衝突を避けるためです。ハイフンの有無だけで区別する構成は、表記の揺れと口頭での説明に耐えません。

技術の前提(AIが解こうとしている部分)

#	前提	崩れると	出典
A-T1	高品質なモデル(ハルシネーション率が人間の検証で吸収できる範囲)	生成物が信用できず検証コストが爆発する	AWS AI-DLC
A-T2	エージェントが長期タスクを自律遂行できる	ステップ数が増えると成功率が幾何級数的に低下する	METR
A-T3	AIの自己検証(テストで自己修正)が機能する	テスト自体の正しさを誰が保証するかが循環する	Anthropic
A-T4	包括的な自動テストとCI基盤が既にある	自己検証の前提が崩れる	AWS AI-DLC

個人・スキルの前提(人間に残る部分)

#	前提	崩れると	出典
A-P1	価値判断能力(作るべきかを判断できる)	AIに判断を委ね、価値判断そのものが空洞化する	CIO
A-P2	言語化能力(意図を曖昧さなく仕様に落とせる)	AIに渡す仕様が不完全になる	Sean Grove
A-P3	検証能力(AI生成物が仕様を満たすか評価できる)	誤りを見抜けず受動的承認者に堕す	AWS AI-DLC
A-P4	これらの能力が希少でなく個人に揃う	希少資源がコード能力から判断能力へ移るだけで偏在は解消しない	PO中心編成の調査

組織・責任の前提(組織に残る部分)

#	前提	崩れると	出典
A-O1	意思決定の権限が個人にある(組織全体がその決定を尊重する)	決めても承認が職位階層で滞留する	Scrum Guide 2020
A-O2	説明責任が一意に紐づく(明確な責任者)	AIの説明責任が拡散し、誰も責任を負わない	Big Agile
A-O3	人間の検証キャパシティが生成速度に追随できる	チェックポイントが形骸化する(rubber stamp化)	awslabs/aidlc-workflows

情報・知識の前提(明文化コストが残る部分)

#	前提	崩れると	出典
A-K1	ビジネス意図が言語化可能(全員が作るものに合意できる)	レガシー・暗黙知の多い現場ほど成立しない	AWS AI-DLC
A-K2	暗黙知を形式知に表出化できる	表出化コストが発生し、言語化不能な残余は渡らない	ポランニーの逆説
A-K3	ステアリングファイル等のガードレールが正しく符号化されている	規制・セキュリティ・組織標準がAIに伝わらない	Anthropic

どの前提が実際に崩れやすいか

前提を列挙するだけでは、どれを重点的に見るべきかが決まりません。崩れやすさを実証データの有無とあわせて評価しました(2026-08-06 時点)。

14 件のうち、崩れやすいと断定できるのは 3 件です。9 件は評価する材料がありません。

前提	評価	根拠
A-T3 AIの自己検証	崩れやすい	テストを通すのではなく、テストの削除・閾値の引き下げ・検査条件の改変によって通す挙動が報告されている。判定器を作った主体が判定器を評価する構造そのものに独立性の喪失がある
A-P3 検証能力	崩れやすい	自動化バイアス、自動化の逆説、レビュー対象が AI 生成物である場合のレビュア側の態度の変化
A-O3 検証キャパシティ	既定で崩れている	1回のレビューは 200〜400 行を超えるべきでないという研究がある一方、AI 支援の変更は既にその上限付近に達している
A-T1 高品質なモデル	崩れにくい方向	ただし前提文の後半(人間の検証で吸収できる範囲)は A-O3 と不可分であり、単独では測る意味が薄い
A-T2 長期タスクの自律遂行	二値では評価できない	到達できるタスクの長さは連続量であり、要求する成功率によって変わる。「崩れた/崩れない」で表せない
A-T4 / A-O1 / A-O2 / A-K3	評価不能(分布のデータがない)	ただし自組織については機械的に判定できる(下記の劣化の定義)
A-P1 / A-P2 / A-P4 / A-K1 / A-K2	評価不能(実証がない)	測る尺度そのものが確立していない。尺度がないことを記録しておくことに意味がある

注意

広く流通する「要件起因の欠陥が◯%」といった数値は、再現できないという査読上の指摘があるため用いていません。評価不能と書いた項目に、根拠のない数値を当てはめないでください。

充足状況の監視と、崩れた場合の手続は第7章 7.10に規定します。

この一覧の使いみち

この前提条件一覧が、フェーズ3(ギャップ分析)の物差しになります。フェーズ1で整理した日本企業のガバナンスと突き合わせると、特に個人・組織・知識の前提(P・O・K)が日本の現場で系統的に崩れることが見えます。

• A-O1(個人の決定権)↔ 決裁は金額×職位で決まる
• A-O2(説明責任の一意性)↔ 稟議は責任を分散する装置
• A-K1・A-K2(言語化・表出化)↔ ハイコンテキストの暗黙知

つまり本プロジェクトの介入点は、AIが解く技術の前提(T)を待つことではなく、P・O・Kの前提を日本の組織文化の中で成立させる仕組みを設計することにあります。この設計がフェーズ3以降の主題です。

崩れた前提はフェーズ4のどこで扱われたか

本ページは前提の一覧であり、規定ではありません。崩れる前提への対処はフェーズ4で要求事項になりました。

前提	フェーズ4での対処
A-T3 AIの自己検証	第5章 5.8.4 テスト生成における分離の段階。実装とテストを同一のAIに同一の文脈で書かせない
A-P3 検証能力	第5章 5.6.2 欠陥注入による検出能力の測定
A-O1 意思決定の権限	第3章 3.8.2 決裁権限マトリクス、第6章 テンプレ0 D-0
A-O2 説明責任の一意性	結果責任は1名。AIを結果責任に割り当てない(テーラリングの禁止事項)
A-O3 検証キャパシティ	第4章 レビュー SLA と帯域の上限、第6章 認知強制機能
A-K1・A-K2 言語化・表出化	第3章 3.11 指示資産、コンテキスト基盤
A-K3 ガードレールの符号化	第3章 3.11.3 強制層。遵守が必須の規則を誘導層に書かない

上表は個別の対処です。前提一覧を物差しとして充足状況を監視し、崩れた状態でどう進むかを決める手続は第7章 7.10に規定します。

ノート

各前提の詳細な根拠は、フェーズ2の個別ページ(AIDLC、エージェント型開発、PO中心編成、コンテキストエンジニアリング)と、research/phase2/ の各調査メモにあります。