第1章：エンジニアの思考 OS - AI ネイティブ環境における意思決定 OS
AI ネイティブな開発・運用では、優れたエンジニアと平均的なエンジニアの差は、AI ツールの利用回数ではなく、問いの設計、根拠の扱い、検証責任、最終判断の引き受け方に表れる。 AI は、調査、要約、候補生成、実装草案、レビュー観点出しを高速化する。一方で、AI の出力は、前提の誤り、古い知識、根拠の欠落、過度な断定、権限境界の見落としを含み得る。
本章では、AI を含む実務で使う「思考 OS」を定義する。ここでいう思考 OS とは、状況を入力し、問いを構造化し、根拠を評価し、選択肢を比較し、検証可能な判断として成果物に残すための基本動作である。
この章で扱う判断
本章で扱う判断は、次の4つである。
- AI へ渡すべき文脈と、渡してはいけない情報をどう分けるか。
- AI 出力を、どの schema、根拠、検証手順で評価するか。
- 不確実性が残る状態で、何を決め、何を保留し、どこへ escalation するか。
- AI に任せる作業、人がレビューする作業、人が最終責任を持つ判断をどう切り分けるか。
誰向けか
- IC / Senior Engineer: 調査、実装案、レビュー指摘を、判断メモや PR に説明可能な形で残したい人。
- Tech Lead: チームの AI 利用を、属人的な勘ではなく、共通の問い・検証・承認ルールへ落としたい人。
- Architect: workflow / agent、RAG、tool 実行の採否を、第3章の ADR へつなげる前提判断として整理したい人。
- EM / SRE / Security: 生産性だけでなく、検証コスト、監査証跡、権限、失敗時の説明責任を確認したい人。
章末に残るもの
この章を読み終えた時点で、次の成果物を作れる状態を目指す。
- 判断メモ
- 前提 / 仮説ログ
- 調査 → 判断 → 検証の最小ループ
- 良い問い / 悪い問いの対比例
- Delegate / Review / Own の責任境界
よくある失敗
| 失敗 | 何が起きるか | 防止策 |
|---|---|---|
| 問いが悪い | AI がもっともらしいが使えない回答を返す | 目的、制約、判断点、出力 schema を先に書く |
| 根拠が薄い | AI 要約が一次情報のように扱われる | source hierarchy を決め、根拠種別を明記する |
| 出力だけを見る | 前提や入力データの偏りを見落とす | 前提 / 仮説ログを更新しながら読む |
| 文章品質を正しさと誤認する | 自然な説明を正しい判断として採用する | テスト、実測、レビュー、再現手順で検証する |
| 責任境界が曖昧 | 事故時に誰が承認し、何を戻すか説明できない | Delegate / Review / Own と rollback を先に決める |
本章と AI 協働の標準手順（SOP）
本章は、AI 協働の標準手順（SOP） のうち、特に次の工程に対応する。
- Issue 化: 目的、利用者、意思決定点、成功条件、制約を明文化する。
- 情報分類: 機密、個人情報、契約情報、利用禁止情報を分ける。
- Plan 作成: decision owner、reviewer、escalation 先、停止条件を決める。
- 入力設計: 前提、根拠資料、source hierarchy、出力 schema、禁止事項を定義する。
- 評価設計: acceptance criteria、eval plan、guardrail metric、手動確認範囲を決める。
本章の目的は、AI を使った作業を増やすことではない。AI 出力を、実務上の責任を持てる判断へ変換することである。
1.1 問いと context engineering
AI ネイティブな実務では、問いは単なるプロンプトではない。問いは、目的、制約、入力情報、判断権限、失敗条件、期待する成果物を束ねた設計対象である。この設計を、本書では context engineering と呼ぶ。
context engineering の目的は、AI に大量の情報を渡すことではない。判断に必要な文脈を十分に与え、不要な情報、投入禁止情報、判断を歪める情報を分離することである。
1.1.1 文脈の最小単位
AI へ作業を依頼する前に、次の7項目を確認する。
| 項目 | 確認すること | 例 |
|---|---|---|
| 目的 | 何を決めるための作業か | RAG を採用するか、通常検索で十分かを判断する |
| 利用者 | 誰の意思決定を支援するか | Tech Lead、Security、SRE、Product Owner |
| 制約 | 納期、予算、既存システム、契約、運用体制 | 2週間で PoC、個人情報は外部 AI 投入不可 |
| 根拠資料 | 何を一次情報として扱うか | 公式仕様、実測ログ、既存 ADR、障害報告 |
| 禁止事項 | AI へ渡さない情報、実行させない操作 | 顧客データ、秘密鍵、本番操作、契約文書の全文 |
| 出力形式 | どの schema で返すか | 比較表、判断メモ、リスク登録票、PR 本文 |
| 停止条件 | どの状態なら判断を止めるか | 根拠不足、権限不明、影響範囲未確定、承認者不在 |
この7項目が曖昧なまま AI に依頼すると、AI は形式上は整った回答を返す。しかし、その回答は判断の責任を支える証拠にならない。
1.1.2 悪い問いと良い問い
悪い問いは、作業対象だけを示し、判断条件を示さない。
この設計をレビューしてください。
この問いでは、AI は一般的なレビュー観点を返す可能性が高い。何を採用判断するのか、どのリスクを優先するのか、誰が責任を持つのかが分からない。
良い問いは、判断点、制約、根拠、出力形式、責任境界を明示する。
目的: 社内ナレッジ検索に RAG を採用するか判断したい。
制約: 個人情報と契約情報は外部 AI へ投入不可。初期 PoC は4週間以内。
根拠: 既存 FAQ 120件、問い合わせログの匿名化サンプル、セキュリティ基準。
判断点: 通常検索、RAG、tool 実行型 workflow のどれが妥当か。
出力: 選択肢比較表、主要リスク、検証すべき仮説、判断保留条件。
禁止: 特定ベンダーの価格比較ではなく、判断原則として整理する。
この問いであれば、AI の出力をそのまま採用しなくても、比較軸、仮説、検証計画の草案として利用できる。
1.1.3 context を増やす前に削る
AI へ文脈を追加する前に、削るべき情報を確認する。
- 個人情報、顧客情報、契約情報、秘密情報、認証情報を含まないか。
- 判断に不要な過去の議論や感情的な表現が混ざっていないか。
- 現在の前提と、すでに無効になった前提が混在していないか。
- AI に判断させてはいけない承認、法務判断、リスク受容が含まれていないか。
- 事実、推測、意見、希望が分離されているか。
文脈を整理することは、AI の回答精度を上げるだけではない。後から「なぜこの判断に至ったか」を説明するための監査証跡にもなる。
1.2 structured output / schema-first thinking
AI 出力を実務へ接続するには、文章ではなく schema を先に決める。schema-first thinking とは、AI に自由作文をさせる前に、採用判断に必要な項目、型、許容値、根拠欄、未確定欄を決める考え方である。
1.2.1 自由作文を避ける理由
AI の自由作文は読みやすい。しかし、読みやすさは検証しやすさと同じではない。実務では、次の観点を機械的に確認できる形式が必要である。
- 根拠はあるか。
- 前提は明示されているか。
- 未確定事項は残っているか。
- 採用しない選択肢の理由はあるか。
- security / privacy / compliance / approval / audit / rollback の観点は抜けていないか。
- 判断者と承認者は分かれているか。
1.2.2 判断メモ schema
本章で使う最小の判断メモ schema は次のとおりである。
| 項目 | 内容 |
|---|---|
| 判断対象 | 何を決めるか |
| 背景 | なぜ今決める必要があるか |
| 選択肢 | 採用候補と却下候補 |
| 根拠 | 一次情報、実測、公式文書、既存成果物への参照 |
| 前提 | 判断が成立する条件 |
| 不確実性 | まだ分からないこと、検証が必要なこと |
| リスク | 品質、安全、運用、法務、コスト、組織面のリスク |
| 統制 | approval、audit、rollback、manual takeover の方針 |
| 判断 | 採用、却下、保留、追加検証のいずれか |
| owner | 最終判断者、reviewer、承認者 |
| 次アクション | 誰が、いつ、何を確認するか |
AI へ依頼する場合は、この schema を指定して出力させる。欠落欄があれば、それ自体が「判断できない理由」になる。
1.2.3 schema の粒度を状況に合わせる
すべての判断に詳細な schema は不要である。小さな判断には軽量 schema、大きな判断には詳細 schema を使う。
| 判断の種類 | 例 | 適切な schema |
|---|---|---|
| 軽微な作業判断 | ドキュメントの表現修正、レビュー観点の追加 | 目的、変更内容、検証、リスク |
| 実装方針判断 | ライブラリ採用、API 設計、テスト方式 | 選択肢、根拠、トレードオフ、rollback |
| アーキテクチャ判断 | RAG、workflow / agent、managed service の採否 | ADR、threat model、eval plan、exit strategy |
| 組織判断 | AI 利用ポリシー、承認フロー、監査設計 | risk register、stakeholder map、approval matrix |
schema は、厳密さを増やすためだけに使うのではない。レビュー負荷を減らし、抜け漏れを早期に発見するために使う。
1.3 source hierarchy と不確実性の扱い
AI ネイティブな環境では、根拠の種類を混同しやすい。AI の回答、ブログ記事、公式ドキュメント、実測結果、既存システムのログが同じ重さで扱われると、判断の質は下がる。
本書では、source hierarchy を次の順で扱う。
- 一次情報: 仕様、契約、規程、公式ドキュメント、法務・セキュリティの正式判断。
- 実測: テスト結果、ログ、メトリクス、再現手順、PoC 結果。
- 組織内成果物: ADR、Runbook、既存設計書、過去の postmortem、運用手順。
- 信頼できる解説: 専門家記事、標準化団体やベンダーのガイド、書籍。
- AI 要約: 上記を圧縮した補助情報。単独では採用根拠にしない。
この順序は、常に一次情報だけを使うという意味ではない。短時間で選択肢を洗い出す段階では AI 要約や解説も役に立つ。ただし、採用判断の根拠にするときは、上位の source へ戻る。
1.3.1 不確実性を消さずに管理する
不確実性は、悪いものではない。悪いのは、不確実性が残っているのに、決まったように扱うことである。
判断メモでは、不確実性を次の4種類に分ける。
| 種類 | 例 | 対応 |
|---|---|---|
| 情報不足 | API 制限、契約条件、現行運用の実態が不明 | 一次情報または関係者へ確認する |
| 実測不足 | 性能、費用、失敗率、レビュー負荷が未測定 | 小さな PoC、ログ分析、負荷試験を行う |
| 権限不足 | 誰が承認するか、誰が操作できるか不明 | decision rights と approval を確認する |
| 影響不明 | 失敗時の顧客影響、監査影響、rollback が不明 | risk register と escalation を作る |
不確実性を明示すれば、判断を保留できる。保留は遅延ではなく、誤った自信による事故を防ぐ統制である。
1.3.2 信頼度と検証責任
AI が「高い確度で」と書いても、それは組織の検証責任を免除しない。信頼度は、AI の自己評価ではなく、人間が確認した根拠と検証結果で決まる。
| 出力の状態 | 採用可否 | 必要な確認 |
|---|---|---|
| 根拠なしの断定 | 採用しない | source を要求し、前提を分解する |
| 根拠はあるが古い | 条件付きで保留 | 現在の公式情報または実測で確認する |
| 実測と一致 | 採用候補 | 再現手順、影響範囲、rollback を確認する |
| 重要判断に関わる | 単独採用しない | reviewer、承認者、監査ログを追加する |
検証責任は、AI ではなく人間側にある。AI は検証観点を提案できるが、検証の成立、採用、リスク受容を決めるのは人間である。
1.4 delegate / review / own
AI 協働の責任境界は、delegate、review、own の3層で整理する。
| 層 | AI にできること | 人間が行うこと | 成果物 |
|---|---|---|---|
| Delegate | 候補生成、要約、比較表、草案、レビュー観点の提示 | 入力情報を選び、禁止事項を指定する | prompt、入力範囲、禁止事項 |
| Review | テスト観点、矛盾点、代替案、リスク候補を出す | 根拠、再現性、安全性、組織制約を確認する | verification record、review checklist |
| Own | 判断メモの草案を作る | 採用、却下、保留、リスク受容、承認、説明を行う | ADR、PR、Runbook、approval log |
AI に任せる範囲を明確にすると、AI 活用は遅くならない。むしろ、レビューで確認すべき点が明確になり、手戻りが減る。
1.4.1 AI に任せてよい作業
- 選択肢の洗い出し
- 比較表の初稿
- 既存文書の要約
- 前提・未確定事項の抽出
- テスト観点、レビュー観点、リスク観点の列挙
- PR 本文、ADR、Runbook の草案
ただし、入力情報の分類と禁止事項の指定は人間が行う。AI に「適切に扱って」と任せない。
1.4.2 人がレビューする作業
- 出力が source hierarchy に沿っているか。
- 実測、テスト、再現手順があるか。
- security / privacy / compliance / approval / audit / rollback が抜けていないか。
- 組織の責任分界、権限、既存運用に合っているか。
- 失敗時に誰が止め、誰が説明し、どう戻すかが分かるか。
レビューは、AI の文章を読みやすく直す作業ではない。実務で採用できる証跡に変換する作業である。
1.4.3 人が最終責任を持つ判断
- 本番環境へ影響する変更の採用
- 顧客情報、個人情報、契約情報の扱い
- 権限付与、外部連携、tool 実行の承認
- 法務、セキュリティ、監査、経営への説明
- リスク受容、rollback 方針、manual takeover の判断
- 事故時の説明、postmortem、再発防止
AI が提案したとしても、これらの判断は人間と組織が引き受ける。責任の所在が曖昧な判断は、採用してはいけない。
1.5 decision rights と escalation
AI 支援により、調査と草案作成は速くなる。しかし、判断権限が不明なまま作業だけが進むと、最後に承認不能な成果物が残る。
decision rights とは、誰が何を決められるかを明文化したものである。AI ネイティブな実務では、decision rights と escalation を作業開始時に確認する。
1.5.1 判断権限の分解
| 判断 | 主な owner | escalation 先 | 証跡 |
|---|---|---|---|
| 技術方針 | Tech Lead / Architect | Architecture board、CTO | ADR、比較表 |
| AI 入力情報 | Data owner / Security | 法務、情報管理部門 | data boundary table |
| tool 実行権限 | SRE / Platform owner | Security、運用責任者 | approval log、audit log |
| リリース可否 | Release owner | EM、SRE、Product Owner | release checklist |
| リスク受容 | Business owner | 経営、法務、監査 | risk register、判断メモ |
この表は、役職名を固定するものではない。組織ごとに owner は異なる。重要なのは、誰も決められない状態を作らないことである。
1.5.2 escalation すべき条件
次の条件に該当する場合、個人判断で進めない。
- 機密情報、個人情報、契約情報の扱いが不明である。
- AI または agent が外部ツールを実行する。
- 本番環境、顧客影響、金銭影響、監査影響がある。
- rollback または manual takeover の手段がない。
- AI 出力の根拠が source hierarchy の上位情報で確認できない。
- リスク受容の owner が不明である。
escalation は、失敗ではない。判断権限を正しい場所へ戻すための統制である。
1.6 調査 → 判断 → 検証の最小ループ
AI ネイティブな思考 OS は、長い分析資料を作ることではない。小さく調査し、判断し、検証し、成果物に残すループを回すことである。
1. 調査: 問い、前提、根拠、選択肢、不確実性を集める。
2. 判断: 採用、却下、保留、追加検証を決める。
3. 検証: テスト、実測、レビュー、再現手順、承認で確認する。
4. 記録: 判断メモ、ADR、PR、Runbook、postmortem へ反映する。
このループは、1回で完了しなくてよい。むしろ、1回で完了したように見える判断ほど、前提や検証が抜けている可能性がある。
1.6.1 判断メモの例
判断対象:
社内ナレッジ検索で RAG を採用するか。
背景:
問い合わせ対応の初動時間を短縮したい。ただし、部門ごとのアクセス制御が必要。
選択肢:
A. 通常検索を改善する。
B. RAG を採用する。
C. tool 実行型 workflow まで拡張する。
根拠:
既存 FAQ、匿名化した問い合わせログ、セキュリティ基準、PoC 結果。
前提:
個人情報と契約情報は外部 AI へ投入しない。検索対象は部門別に分離する。
不確実性:
引用漏れ率、権限境界の実装コスト、回答確認に必要なレビュー負荷。
統制:
初期版は回答提案のみ。外部送信や更新操作は行わない。
approval は部門 owner、audit は問い合わせ ID と参照文書 ID を残す。
誤回答時は通常検索へ fallback し、manual takeover を運用担当が行う。
判断:
RAG の小規模 PoC を実施する。ただし、本番採用は eval plan と権限検証後に判断する。
次アクション:
Tech Lead が eval plan を作成し、Security が data boundary を確認する。
1.6.2 前提 / 仮説ログの例
| ID | 種別 | 内容 | 根拠 | 状態 | 次アクション |
|---|---|---|---|---|---|
| A-01 | 前提 | 外部 AI へ個人情報は投入しない | 社内規程 | 確認済み | prompt と入力手順に明記 |
| H-01 | 仮説 | RAG で初動調査時間を30%短縮できる | 問い合わせログ | 未検証 | PoC で処理時間を計測 |
| Q-01 | 質問 | 部門別アクセス制御を既存 IdP で実装できるか | 現行設計不明 | 未確認 | Platform owner へ確認 |
| R-01 | リスク | 誤回答が顧客説明へ転用される | 運用手順未整備 | 対応中 | 承認前の外部送信を禁止 |
このログは、AI に渡すためだけではなく、チームの合意形成と監査証跡のために残す。
1.7 失敗パターンと修正方法
1.7.1 問いが悪い
悪い問いは、判断点を曖昧にする。
AI 活用で生産性を上げる方法を考えてください。
修正後は、対象、制約、測定方法、責任境界を含める。
対象: PR レビューの初動観点出し。
制約: 機密コードを外部 AI に投入しない。既存 CI 結果を前提にする。
測定: review rework、escaped defects、レビュー時間、説明責任の記録率。
責任境界: AI は観点出しのみ。承認は reviewer が行う。
1.7.2 根拠が薄い
AI が一般論を返した場合、採用判断に使う前に根拠を分解する。
- どの source に基づくか。
- 現在のシステムに当てはまるか。
- 実測または再現手順はあるか。
- 反例や失敗条件は何か。
- どの条件なら採用しないか。
1.7.3 出力だけ見て前提を見ない
AI 出力は、入力された前提に強く依存する。前提が古い、偏っている、欠けている場合、出力も歪む。
前提を確認するには、判断メモに次の欄を必ず置く。
- 採用した前提
- 捨てた前提
- 未確認の前提
- 前提が崩れた場合の影響
- 前提を検証する方法
1.7.4 AI の文章品質を正しさと誤認する
自然な文章、説得力のある構成、網羅的に見える箇条書きは、正しさの証拠ではない。正しさは、根拠、実測、レビュー、再現手順、承認によって確認する。
特に、security / privacy / compliance / approval / audit / rollback に関わる判断では、AI の説明だけで採用しない。必ず責任者と承認条件を明示する。
まとめ
本章では、AI ネイティブ環境における意思決定 OS を定義した。重要なのは、AI の出力を速く得ることではなく、問い、文脈、schema、根拠、不確実性、責任境界を通じて、採用できる判断へ変換することである。
本章の要点は次のとおりである。
- context engineering は、AI へ大量の情報を渡すことではなく、判断に必要な文脈と禁止情報を分けることである。
- schema-first thinking により、AI 出力をレビュー可能な成果物へ変換できる。
- source hierarchy を明確にし、AI 要約を単独の採用根拠にしない。
- 不確実性は隠さず、情報不足、実測不足、権限不足、影響不明に分けて管理する。
- Delegate / Review / Own によって、AI に任せる作業、人がレビューする作業、人が最終責任を持つ判断を分ける。
- decision rights と escalation を先に決めることで、承認不能な成果物を防げる。
この章のまとめとチェックリスト
この章のまとめ
AI ネイティブな思考 OS は、問いを構造化し、出力 schema を決め、根拠を階層化し、不確実性を管理し、責任境界を成果物に残すための基本動作である。この基本動作がなければ、AI 活用は速度だけを上げ、検証不能な負債を増やす。
この章を読み終えたら確認したいこと
- AI へ依頼する前に、目的、制約、判断点、禁止事項、出力 schema を書ける。
- AI 出力の根拠を source hierarchy に沿って分類できる。
- 不確実性を、情報不足、実測不足、権限不足、影響不明に分けられる。
- AI に任せる作業、人がレビューする作業、人が最終責任を持つ判断を説明できる。
- approval、audit、rollback、manual takeover のいずれかが必要な判断を識別できる。
- 判断メモ、前提 / 仮説ログ、調査 → 判断 → 検証の最小ループを実務へ適用できる。
関連する付録・テンプレート
- AI 協働の標準手順（SOP）
- 付録A：実務成果物テンプレート集
- 付録D：更新方針と更新履歴 - モデル名、価格、UI、API 細部など変化しやすい情報を、判断原則から切り分けて更新する基準を確認する。