第3章 AIを使い、検証して進める

第2章では、支援ステータス機能について、要望、課題、成果、制約、MVPを整理した。第3章では、その整理を持ったうえでAIを使う。

AIは、分からないことを聞く相手としても、文章やコードの下書きを作る道具としても役に立つ。しかし、AIに聞けば仕事の責任が移るわけではない。 AIの出力を使うかどうかを決めるのは人であり、その出力をどう確かめたかを説明するのも人である。

この章で学ぶのは、AIを禁止することではない。 AIを安全に、説明可能に、検証可能に使うための境界を作ることである。

この章でできるようになること

この章のゴールは、AIを上手に使っている雰囲気を出すことではない。 AIを何のために使い、どこまで任せ、何を自分で確認したのかを説明できるようになることである。

この章を読み終えたら、次のことができる状態を目指す。

第2章のDecision Memoをもとに、AIへ渡す前提を短く整理できる。
AIに相談すること、任せたい作業、任せない判断を分けられる。
AIに渡してよい情報と、渡してはいけない情報を区別できる。
AI出力を、採用する提案、採用しない提案、未検証の提案に分けられる。
技術説明、コード案、要件案、セキュリティ案、文章案に応じて検証方法を選べる。
ai-use-plan.md に、目的、前提、依頼文、禁止事項、検証方法を書ける。
ai-use-log.md に、渡した情報、出力要約、採用判断、検証結果、残るリスクを書ける。

AIの出力が正しいかどうかを、文章の自然さだけで判断しない。公式ドキュメント、リポジトリ内のREADMEやコード、実行結果、テスト、関係者確認を使って、仕事に使える情報へ変える。

AIに渡す前に、仕事を小さくする

AIへの依頼がうまくいかない理由の多くは、AIの性能だけにあるのではない。人間側の依頼が曖昧なままになっていることが多い。

たとえば、次のように依頼したとする。

「支援ステータス機能を作る方法を教えて」

この依頼では、AIは一般的な回答を返すしかない。誰が使うのか、何を成果とするのか、今回は何を作らないのか、どの技術スタックなのか、どこまで自動で作業してよいのかが分からないからである。

第2章で作った整理を使うと、依頼は次のように変えられる。

「メンターが担当受講者一覧で支援が必要な人を早く見つけられるようにしたい。初回MVPでは、一覧に支援ステータスを表示するところまでを対象にする。通知、CSV出力、詳細な更新履歴は今回は対象外。要件整理の観点として、見落としている制約や確認事項を挙げてほしい。」

この依頼なら、AIは何を助ければよいかを判断しやすい。 AIを使う前に、目的、範囲、非対象、期待する出力を人が決めているからである。

AI活用の第一歩は、よいプロンプトを書くことではない。 AIに渡す前に、仕事を小さくし、文脈を整えることである。

AIに任せやすいこと、任せにくいこと

AIには、任せやすい作業と、任せにくい作業がある。ここを分けずに使うと、便利そうな出力をそのまま採用してしまう。

AIに任せやすいのは、候補を広げる作業である。たとえば、支援ステータス機能について、確認すべき制約の候補を出す、Decision Memoの下書きを整える、レビュー観点を洗い出す、テスト観点の初期案を作る、といった使い方である。

一方で、AIに任せきれないこともある。業務上の最終判断、機密情報の扱い、実際のデータの正しさ、権限設計の採否、テスト結果の解釈、リリース可否の判断である。これらは文脈と責任を伴うため、人が確認しなければならない。

もう少し分けると、次のように考えられる。

作業	AIに任せやすい使い方	人が確認すること
不明点の洗い出し	確認質問の候補を出す	実際に誰へ確認するか、どれが今回必須か
作業計画	手順や優先順位の候補を出す	期限、担当、既存の制約に合うか
技術調査	調査観点や公式資料候補を出す	公式資料を開いて内容と日付を確認する
文書作成	メモやPR説明の下書きを作る	事実関係、言い過ぎ、未確認事項の扱い
コード修正案	小さな差分案やテスト観点を出す	差分、テスト、既存設計、セキュリティ

支援ステータス機能で考えると、AIは「支援ステータスにはどんな状態名があり得るか」を提案できる。しかし、その状態名が自社の研修運用に合っているか、メンターが誤解しないか、受講者に不利益が出ないかは、人が確認する必要がある。

AIは、考える材料を増やす道具である。採用する判断を代わりに持つ道具ではない。

渡してよい情報と、渡してはいけない情報

AIを使うときは、何を渡すかだけでなく、何を渡さないかを決める。特に実務では、便利さよりも先に情報の扱いを確認する必要がある。

渡してよい情報の例は、公開されている仕様、抽象化した業務例、機密を含まないエラーメッセージ、個人を特定できない形にしたサンプルデータである。渡してはいけない情報の例は、顧客情報、個人情報、認証情報、APIキー、未公開の事業情報、社外秘の文書、実際の本番データである。

支援ステータス機能でAIに相談する場合も、実在する受講者名や個別の評価、面談内容を渡してはいけない。必要なら、次のように抽象化する。

悪い例：受講者Aさんは最近欠席が続いていて、面談内容は…。
よい例：ある受講者について、メンターが支援要否を判断するためのステータスを表示したい。

AIに渡す情報は、少なすぎると役に立たない。しかし、多ければよいわけでもない。必要な文脈だけを選び、出してはいけない情報を除くことが、AI利用の基本になる。

入力前には、少なくとも次を確認する。

APIキー、パスワード、トークン、Cookie、秘密鍵が含まれていない。
実在する個人名、メールアドレス、評価、面談内容、顧客情報が含まれていない。
社外秘の仕様、未公開の事業情報、契約や法務確認中の文章が含まれていない。
本番ログや本番データを、そのまま貼っていない。
会社や研修で許可されたAIツールと利用ルールに合っている。

迷ったときは、渡す前に抽象化する。それでも判断できないなら、AIへ入れる前にメンターやチームへ確認する。

出力を使う前に、検証方法を決める

AIの出力は、自然な文章で返ってくる。そのため、正しいように見えやすい。しかし、文章が自然であることと、仕事に使えることは別である。

検証とは、AIの出力をそのまま信じず、別の方法で確かめることである。検証方法は、出力の種類によって変わる。

技術説明：公式ドキュメントや信頼できる資料と照合する。
コード案：テスト、lint、実行結果、差分レビューで確認する。
要件案：利用者、メンター、関係者に確認する。
セキュリティ案：社内ルール、OWASPなどの標準、実際の権限設計と照合する。
文章案：読者、目的、事実関係、言い過ぎがないかを確認する。

AI出力で特に起きやすい問題も、先に知っておくと検証しやすい。

存在しないAPI、設定値、コマンドをもっともらしく書く。
古いバージョンの情報を、現在も正しいものとして書く。
このプロジェクトにはないファイル名、関数名、運用ルールを前提にする。
セキュリティ、権限、ライセンス、アクセシビリティの確認を省く。
不確かなことを、不明ではなく断定として書く。

技術情報や外部サービスの仕様は変わる。 AIの回答や古い記事だけで確定せず、公式ドキュメント、リポジトリ内の実物、実行結果、テスト結果へ戻って確認する。

支援ステータス機能でAIが「緊急」「注意」「順調」という状態名を提案したとする。そのまま採用する前に、少なくとも次を確認する。

メンターが同じ意味で使えるか。
受講者に見える場合、不必要に強い表現にならないか。
データベース上の値として扱いやすいか。
APIや画面で説明しやすいか。
テストで期待値として書けるか。

AIの提案を採用するとは、AIが言ったことを信じることではない。人が確認し、採用する理由を説明できる状態にすることである。

採用、見送り、未検証に分ける

AIの出力を読んだ直後は、よさそうな提案がすべて同じ重さに見えやすい。そこで、まず三つに分ける。

採用する提案：目的と制約に合い、検証方法が見えているもの。
採用しない提案：目的から外れる、リスクが大きい、初回範囲に入れない理由を説明できるもの。
未検証の提案：よさそうだが、既存コード、公式資料、関係者確認、実行結果をまだ見ていないもの。

実装前に追加確認が必要な場合は、「採用候補」と書いてよい。採用、採用候補、未検証を無理に同じ箱へ入れないことが大事である。

たとえばAIが、未提出者フィルタ、CSV出力、自動通知、権限チェック、ステータス説明文を提案したとする。第2章のDecision Memoと照らすと、未提出者フィルタとステータス説明文は採用候補にできるかもしれない。 CSV出力と自動通知は、初回MVPの目的から外れるため見送る判断ができる。権限チェックは重要だが、既存の認可実装をまだ見ていないなら未検証として残す。

未検証を残すことは、負けではない。むしろ、分かっていないことを分かっていないまま扱うために必要である。未検証の提案は、次の調査、質問、テスト、レビュー観点へ変える。

AI利用計画を書く

AIを使う前に、短いAI利用計画を書く。計画を書く目的は、AI利用を重くすることではない。何を任せ、何を任せないかを最初に決めることで、後から判断を説明しやすくするためである。

支援ステータス機能なら、AI利用計画は次のように書ける。

目的: 支援ステータス機能の初回MVPについて、要件の抜け漏れと確認観点を洗い出す。

前提: 第2章のDecision Memoでは、初回MVPを担当受講者一覧で支援ステータスを見つけやすくする範囲に絞っている。通知、CSV出力、詳細な更新履歴は初回では扱わない。

AIに相談したいこと: 利用者、課題、制約、画面状態、テスト観点、セキュリティ確認の候補。

AIに作業計画を相談したいこと: 何を先に確認し、どの順番で画面、API、データ、権限、テストを考えるべきか。

AIに任せたい作業: 確認質問の候補、リスクの洗い出し、設計メモ下書き、テスト観点の候補作成。

AIに任せないこと: 最終的なMVP範囲の決定、実在する受講者情報の扱い、権限設計の採否、リリース可否の判断。

AIに渡す情報: 第2章で整理した抽象的な要望、課題、成果、候補機能、制約。

AIに渡さない情報: 実名、個別の受講状況、面談内容、認証情報、社内秘の運用資料。

AIへの依頼文: 第2章のDecision Memoを前提に、初回MVPの確認事項、見落としやすいリスク、見送るべき案、検証方法を出してもらう。不確かなことは断定せず、不明と書いてもらう。

禁止事項: 初回MVPの範囲を勝手に広げない。実在する受講者情報を前提にしない。未確認の技術仕様や権限設計を確定したように書かない。

検証方法: AIの出力をDecision Memo、課題テンプレート、公式資料、実際の画面確認、メンターへの確認で照合する。

この程度で十分である。大切なのは、AIに何をさせるかだけでなく、AIにさせないことを書く点である。

AI利用ログを書く

AIを使った後は、AI利用ログを書く。ログは、AIの出力をそのまま貼る場所ではない。 AIの出力をどう判断したかを残す場所である。会話全文を貼るよりも、採用判断と検証結果を追えることが重要である。

たとえば、次のように書く。

使用したAIツール: 承認されたAIツール名を書く。

AIに渡した情報: 第2章のDecision Memoの要約と、教材上のケース。実名、個別の受講状況、認証情報、本番データは渡していない。

AIに依頼したこと: 支援ステータス機能のMVPについて、確認すべき観点を洗い出してもらった。

AIの出力要約: ステータス定義、権限、更新履歴、通知、絞り込み、テスト観点、説明文の候補が出た。

採用した提案: 初回MVPでも、ステータスの意味を画面上で説明する必要があるという提案を採用した。

採用しなかった提案: 通知機能と詳細な更新履歴は、初回MVPの目的から外れるため採用しなかった。

未検証の提案: 権限チェックの具体的な実装方法は、既存コードをまだ確認していないため未検証として残す。

確認したこと: 第2章のDecision Memoと照合し、初回の目的が「支援対象を見つけやすくすること」であることを確認した。通知や履歴は、運用方法が決まってから再検討する。

検証結果:

項目	検証方法	結果
初回MVPの範囲	Decision Memoと照合	通知と履歴は初回範囲外
AIに渡した情報	入力内容をチェックリストで確認	実名、認証情報、本番データは含めていない

残る不確実性: ステータス名がメンター間で同じ意味に解釈されるかは、メンターへの確認が必要である。既存の権限実装とAPI設計は、後の章でコードを読んで確認する。

このログがあると、メンターやレビュー担当者は、AIを使ったかどうかだけでなく、AIの出力をどう扱ったかを確認できる。

AI利用で起きやすい誤解

AIに聞いたことを、確認済みの事実として扱う。
便利だからといって、不要な社内情報や個人情報まで渡す。
AIの出力が自然な文章だったため、検証せずに採用する。
AI利用ログを、使ったツール名だけで終える。
AIに任せないことを決めず、作業範囲が広がりすぎる。
採用しない提案や未検証の提案を記録せず、あとで判断理由が分からなくなる。
公式資料や実行結果で確認する前に、AIの説明をPRや設計メモへ事実として書く。

AI利用計画とログで確認すること

ai-use-plan.md と ai-use-log.md を作り、AIへ渡した情報と自分で確認した証拠を残す。

ai-use-plan.mdでは、目的、前提、AIに相談したいこと、作業計画として相談したいこと、任せたい作業、任せないこと、渡す情報、渡さない情報、依頼文、禁止事項、検証方法を書く。 ai-use-log.mdでは、使用したAIツール、渡した情報、渡していない情報、AIの出力要約、採用した提案、採用しなかった提案、未検証の提案、検証したこと、残るリスクを書く。

検証結果は、少なくとも二つ以上残す。たとえば、Decision Memoとの照合、公式ドキュメントの確認、リポジトリ内検索、テスト実行、メンター確認、画面確認のどれかである。

AIを使ったこと自体を成果にしない。 AIの出力を、人がどう判断し、どう確かめ、どこまで採用したかを成果にする。

AIを検証して使う章で持ち帰ること

第3章で身につけるべきことは、AIを使う前に境界を決め、使った後に検証結果を残すことである。 AIは候補を広げ、下書きを作り、作業を速くできる。しかし、目的、機密情報、採用判断、検証、説明責任は人が持つ。

第2章で整理した価値やMVPは、AIに依頼するときの重要な入力になる。目的が曖昧なままAIを使えば、出力も曖昧になる。目的、範囲、制約、検証方法を持ってAIを使うことで、AIは実務の中で安全に役立つ道具になる。 AIが自信ありげに答えても、未確認のものは未確認として扱う。採用したもの、採用しなかったもの、まだ判断しないものを分けて残せれば、チームに対しても自分の判断を説明しやすくなる。

チームに情報を渡す章へ

次章では、AIに限らず、チームの人へ情報を渡す書き方を扱う。 AI利用計画やAI利用ログも、最終的には人に読まれる文書である。相手が次の判断をしやすい形に整理する力が、チーム開発では重要になる。