毎回AIへ同じ説明をしていないか？案件の背景・資料・判断を再利用するコンテキスト設計
新しいチャットを開くたびに、同じ説明をしている。
「今回の対象者は営業担当です」
「研修時間は90分です」
「顧客情報は使えません」
「以前検討した3時間案は廃止しました」
「最新の資料は、このファイルです」
前のチャットでは理解していたはずなのに、別のチャットでは条件が抜ける。古い案が再び提案される。最新版を渡したつもりなのに、旧料金や廃止済みの仕様が回答へ混ざる。
そこで、関連しそうなファイルをすべてProjectへ入れてみる。
ところが、今度は資料が増えすぎて、どれが正式版なのか分からない。過去の検討案と現在の決定が混ざり、重要なルールは長い資料の中へ埋もれてしまう。
こうした問題は、AIが案件を「覚えていない」ことだけが原因ではありません。
案件の目的、正式資料、過去の判断、現在の課題が、再利用できる状態へ整理されていないことが大きな原因です。
AI活用成熟度のフェーズ6では、一つの確認済み情報基盤から、記事、スライド、画像、FAQ、SNS投稿などを一貫して制作しました。
フェーズ7では、その情報基盤を単発の制作で終わらせず、複数のチャットや担当者が継続的に参照できる案件コンテキストへ変えます。
AIと長期案件を安定して進める鍵は、すべてを覚えさせることではありません。案件の目的、正式資料、過去判断、品質基準、未解決事項を役割別に整理し、必要な文脈だけを最新版として参照できる状態を維持することです。
このシリーズでは、AI活用が単発利用から業務・組織の再設計へ進む過程を、12のフェーズに分けて解説します。
フェーズ7では、会話を長くするのではなく「案件の現在状態」を再現できるようにする
フェーズ7の「個人・案件コンテキスト設計」とは、AIへ大量の資料を渡すことではありません。
案件を再開するときに、次の状態を再現できるようにすることです。
この案件は何を目的としているか
現在どの段階にいるか
どの資料が正式版か
何が決定済みか
どの案が廃止されたか
何が未解決か
どの品質基準を守るか
誰が判断・承認するか
次に何を行うか
現在の主要AIサービスには、案件単位でチャット、指示、資料をまとめる機能があります。
ChatGPT Projectsは、関連するチャット、参照ファイル、プロジェクト指示を一つの作業空間へまとめる仕組みです。プロジェクト限定メモリを選ぶと、同じプロジェクト内の会話を参照しながら、プロジェクト外の会話や保存済みメモリから分離できます。
Claude Projectsも、案件ごとのチャット、プロジェクト指示、ナレッジベースを持つワークスペースです。ナレッジ量が増えた場合は、すべての資料を一度に読み込むのではなく、質問と関連する箇所を検索するRAG方式が使われます。
Gemini APIには、長い入力を扱う長文脈機能や、繰り返し使う入力トークンを効率化するコンテキストキャッシュがあります。ただし、キャッシュは同じ入力処理の速度やコストを最適化する仕組みであり、どの資料が正式版か、どの判断が有効かを管理する案件台帳ではありません。
つまり、AIサービスが文脈を保持・検索できることと、正しい文脈が整理されていることは別です。
フェーズ7では、案件コンテキストを次の8段階で設計します。
案件の境界を決める
情報を役割別に分類する
案件概要と上位ルールを固定する
正式資料・参考資料・旧版を分ける
判断・変更・未解決事項を記録する
AIが参照できる構造へ配置する
取得・回答・権限を検証する
定期的に更新・圧縮・引き継ぐ
この8段階の目的は、AIへすべてを記憶させることではありません。
案件の正しい状態を、必要なときに再現できるようにすることです。
長い会話履歴があっても、最新版や正式決定は保証されない
長期案件では、会話履歴が大量に残ります。
しかし、その中には次の情報が混在しています。
採用前の案
一時的な仮説
誤っていた前提
撤回された指示
試作品
廃止された文章
AIの誤答
正式決定前の議論
会話の中で「これでいきましょう」と書かれていても、後から変更されているかもしれません。
過去チャットは、経緯を確認する材料にはなります。
ただし、正式な案件台帳や最新版の代わりにはなりません。
重要な判断は、会話から決定ログへ移します。最新版の成果物は、正式資料として別に管理します。
コンテキストは「保存した情報」ではなく「正しく取得できる情報」である
資料をProjectへ置いただけで、毎回その資料が完全に使われるとは限りません。
資料量が多い場合、AIは質問に関連すると判断した箇所を検索・取得します。検索語、文書構造、用語、資料の分割方法によっては、必要な情報が取得されない可能性もあります。
したがって、
ファイルを置いたから、AIは理解している
とは考えません。
重要なのは、
どの情報を参照したか
どの版を使ったか
必要な箇所を取得できたか
旧版を混ぜていないか
情報がないときに推測していないか
を確認できることです。
案件コンテキストは、回答品質だけでなく再開速度でも評価する
案件コンテキストが整うと、新しいチャットや担当者でも、次の作業へ速く移れます。
毎回30分かけて背景を説明していたものが、案件概要と正式資料を参照することで、数分で再開できるかもしれません。
評価する項目は、回答の正確さだけではありません。
案件説明にかかる時間
作業再開までの時間
前提の修正回数
旧版混入の回数
不要な質問の数
担当者間の成果物のばらつき
も確認します。
最初に、どこまでを一つの案件として扱うか決める
案件コンテキストを作る前に、案件の境界を決めます。
境界が曖昧なまま資料を集めると、別の顧客、別の目的、別の権限に関する情報が混ざります。
たとえば、「AI研修」というテーマだけで一つのProjectを作ると、次が同じ場所へ入るかもしれません。
営業部向けの90分研修
経営者向けの3時間研修
医療機関向けの安全研修
社内新人向けの基礎研修
外部販売用のeラーニング
すべてAI研修ですが、対象者、目的、契約、機密性、完成条件が異なります。
類似案件でも、顧客・目的・権限が違う場合は分ける
次の条件が大きく異なる場合は、別案件として扱う方が安全です。
顧客
契約
利用目的
成果物
機密区分
共有メンバー
承認者
保存期限
顧客Aの情報が、顧客Bの提案へ混ざる状態は避けなければなりません。
長期テーマと個別案件を分ける
「生成AI研修に関する一般知識」と「営業部向け研修の制作案件」は別です。
長期テーマ側には、複数案件で再利用できる一般知識を置きます。
案件側には、今回の顧客、対象者、要件、判断、成果物を置きます。
個人・組織の共通設定と案件固有情報を分ける
次のような情報は、複数案件で使える場合があります。
文章では結論を先に置く
数値は原典で確認する
外部送信前に人間が確認する
不確実な情報を断定しない
一方、次は案件固有です。
今回の対象読者
納期
料金
顧客名
禁止用語
使用可能なAI
承認フロー
共通設定を案件ごとに複製すると、更新漏れが起きます。
案件情報を個人の長期メモリへ入れると、別案件へ混ざる可能性があります。
大きな案件では、サブプロジェクトの関係を明示する
長期案件では、次のようなサブプロジェクトが生まれます。
調査
研修設計
教材制作
営業資料
実証
効果測定
全社展開
すべてを別Projectへ分ける必要はありません。
ただし、成果物、責任者、状態、参照元を分けて管理できるようにします。
案件名：
目的：
対象：
開始日：
責任者：
関係者：
含む範囲：
含まない範囲：
関連案件：
共有範囲：
終了条件：情報を「普遍・案件・作業・履歴」の4層へ分ける
案件コンテキストへ何を入れるか迷ったときは、情報を4層へ分けます。
普遍情報
案件情報
作業情報
履歴情報
普遍情報は、個人・組織の長期設定へ置く
普遍情報は、複数案件で長期間使う情報です。
例です。
文章の基本文体
会社名の正式表記
共通のセキュリティ方針
外部送信前に人間承認を必要とするルール
数値・日付・固有名詞を再確認する方針
顧客情報を無断で共有しない方針
ChatGPTの保存済みメモリも、長期的な好みや継続的に役立つ情報を扱うための機能であり、案件固有の要件書や一時的な変更を保管する案件台帳とは役割が異なります。
長期間有効で、複数案件へ本当に適用できる情報へ絞ります。
案件情報は、プロジェクト指示と案件概要へ置く
案件全体で有効な情報です。
案件の目的
対象者
中心命題
契約上の条件
成果物一覧
品質基準
禁止事項
正式な参照元
人間が保持する判断
現在の段階
新しいチャットを始めるたびに繰り返し説明する内容は、案件概要へ昇格させる候補です。
作業情報は、現在の依頼だけに置く
今回だけ有効な情報です。
今回修正する章
今日作る画像
今回の文字数
今回だけ使う参考資料
次の承認ゲート
今回の出力形式
今回の期限
一時的な作業条件を案件の上位ルールへ追加すると、指示が長くなり、後の作業へ不要な制約が残ります。
履歴情報は、決定ログと更新履歴へ置く
履歴情報には次があります。
採用した案
採用しなかった案
変更理由
廃止した前提
過去の版
実証結果
次回の見直し条件
履歴を消してしまうと、なぜ現在の形になったか分からなくなります。
一方、履歴をすべて上位コンテキストへ入れると、古い判断が現在の回答へ混ざります。
そのため、現在有効な状態と、過去の経緯を分けて保持します。
案件概要と上位ルールは、短く参照しやすい形へ固定する
案件コンテキストの入口となるのが、案件概要です。
案件概要は、すべての情報を詰め込む長文ではありません。
AIや新しい担当者が、
何の案件か
現在どこにいるか
何を守るか
どこを参照するか
を短時間で把握するための入口です。
案件の目的は、成果物ではなく変えたい状態で書く
悪い例です。
営業部向けのAI研修資料を作る。
これは成果物しか示していません。
改善例です。
AI初心者の営業担当者が、顧客情報を入力せず、メール作成・要約・商談準備の3業務で、安全にAIを使える状態を作る。
誰の何を変える案件なのかが分かります。
詳細ルールは別ファイルへ分け、案件概要には入口を置く
案件概要へ、すべての執筆ルール、画像仕様、調査基準を入れる必要はありません。
案件概要には、参照先を示します。
調査ルール：
03_調査と根拠管理.mdを参照
記事ルール：
04_note原稿設計と執筆ルール.mdを参照
画像ルール：
05_画像制作ルール.mdを参照上位ルールを短くし、詳細は意味単位の資料へ分けます。
違反すると利用できない条件は、資料の奥へ埋めない
「顧客情報を演習へ使わない」という重大条件が、50ページの資料の37ページ目にだけ書かれている状態は危険です。
違反すると成果物が使えない条件は、案件概要や上位指示へ置きます。
複数資料が競合する場合の優先順位を明示する
優先順位：
1. 最新の顧客承認事項
2. 案件概要
3. 正式要件書
4. 品質基準
5. 参考資料
6. 過去チャットこれにより、古い参考資料が現在の正式要件を上書きすることを防げます。
案件名：
目的：
対象者：
読後・利用後の変化：
中心命題：
現在の段階：
今回の最優先事項：
正式な参照元：
主要成果物：
完成条件：
必須ルール：
禁止事項：
人間承認が必要な箇所：
詳細ルールの参照先：正式資料・参考資料・旧版・未確定資料を分ける
同じフォルダへ資料を入れるだけでは、状態が分かりません。
たとえば、次の4ファイルがあるとします。
研修要件.md
研修要件_修正.md
研修要件_最終.md
研修要件_最終2.md
人間でも、どれが正式版か迷います。
AIがファイル名だけで正しく判断できるとも限りません。
正式資料は、現在の回答の根拠として使える状態にする
APPROVED_2026-07-17_研修要件_v3.md参考資料には、再利用してよい範囲を書く
REFERENCE_競合研修資料_構成参考.pdf資料本文にも、次のように書きます。
状態：REFERENCE
用途：構成と説明方法の参考
禁止：数値・顧客条件・料金を事実として再利用しない旧版は履歴として残し、現在の回答へ混ぜない
SUPERSEDED_2026-06-30_研修要件_v2.md可能なら通常の検索対象から外し、archiveフォルダへ移します。
未確定資料は、事実として使わない
DRAFT_新料金案_v1.xlsx未確定資料を使う場合は、
現在検討中の案であり、正式決定ではない
と明示します。
状態はファイル名だけでなく本文にも書く
検索・RAGでは、ファイル名が十分に参照されない場合があります。
状態：APPROVED
版：v3
確認日：2026-07-17
正式な更新元：本ファイル
旧版：v2は廃止版を増やしすぎず、重要変更だけ履歴を残す
重大な要件変更、数値変更、顧客承認の変更では版を分けます。
軽微な誤字修正まで無制限に版を増やす必要はありません。
過去チャットの重要判断は、決定ログへ昇格させる
長期案件では、多くの判断がチャット内で行われます。
タイトルを変更する
対象者を絞る
画像を5枚にする
旧案を廃止する
小規模実証から始める
特定の数値を削除する
これらを会話履歴だけへ残すと、新しいチャットで見落とされます。
会話中の合意を、正式決定と自動的に扱わない
正式な決定として扱う前に、
何を決めたか
誰が決めたか
どの前提に基づくか
何へ影響するか
を整理します。
採用案・不採用案・理由を残す
条件が変わった際に、過去の不採用案を再検討できます。
決定時点の前提を記録する
まず営業部10名で実証する
という決定は、
全社の利用状況が未確認
研修効果が不明
営業部の対象業務が明確
という前提に基づいているかもしれません。
前提が変われば、判断も見直します。
変更時は、旧決定を削除せず廃止状態にする
状態：SUPERSEDED
後継決定：DEC-014決定ID：
決定日：
決定事項：
状態：
決定者：
根拠：
前提：
採用理由：
不採用案：
不採用理由：
影響する資料・成果物：
見直し条件：
見直し日：未解決事項・仮定・質問は、正式資料と分けて管理する
問題は、未確定の情報が、いつの間にか確定事実として扱われることです。
未確認事実と単なる作業残を分ける
未確認事実：
予算が承認されるか
顧客情報を匿名化すれば使えるか
利用アカウントを会社が用意するか
作業残：
スライドの誤字修正
画像ファイル名の変更
FAQの追加
結論を左右する未確認事実を優先します。
結論を左右する未解決事項を上位へ置く
重要未解決事項：
1. 研修で利用するAIプラン
2. 顧客データの匿名化基準
3. 実証後の全社展開判断者仮定には、未確認ラベルを付ける
現在の仮定：
参加者は20名と仮置きする。
状態：
未確認。正式な人数ではない。解決後は台帳を閉じるだけでなく、正式資料へ反映する
項目ID：
内容：
種別：
重要度：
結論への影響：
現在の仮定：
必要な確認：
確認担当：
期限：
解決後の反映先：
状態：AIが必要情報を参照できる構造へ配置する
情報を分類したら、AIが参照しやすい構造へ配置します。
特定製品のフォルダ機能を使うこと自体が目的ではありません。
情報の役割と優先順位が、構造からも分かる状態を作ることが重要です。
上位ルールはプロジェクト指示へ置く
例です。
正式資料を優先する
旧版を現在の条件として使わない
不足情報は推測せず質問する
外部送信前に人間承認を得る
数値・日付・固有名詞を再確認する
詳細な事実や長い手順は、別資料へ分けます。
詳細な事実は、意味単位の資料へ置く
顧客要件
利用規程
調査結果
商品仕様
契約条件
主張台帳
などは、参照資料として管理します。
正式決定は、検索しやすい決定ログへ置く
過去チャットを探さなくても、現在有効な決定を確認できるようにします。
今回だけの変更は、現在の依頼へ置く
今回は第3章だけを修正する。
タイトルと他章は変更しない。この内容を案件概要へ追加する必要はありません。
大量資料では、検索可能な固有名詞・日付・状態を書く
悪い例です。
前に話したあれは使わない。改善例です。
「3時間の対面研修案」は2026年6月30日に廃止した。
現在は「90分のオンライン研修案」を採用している。重要情報を画像・表の中だけに閉じ込めない
検索や抽出で取りこぼす可能性があるため、重要要件は本文にもテキストで残します。
一つの巨大資料より、更新単位に合わせて分ける
00_案件概要.md
01_現在の状態.md
02_正式要件.md
03_決定ログ.md
04_未解決事項.md
05_用語集.md
06_品質基準.md
07_主張台帳.md
08_成果物一覧.md
09_更新履歴.md
references/
archive/ただし、資料を細かく分けすぎると管理が複雑になります。
役割と更新頻度が同じ情報はまとめて構いません。
「置いたから使われる」と考えず、取得テストを行う
案件資料を配置したら、AIが正しく参照できるか確認します。
正式な数値を質問し、正しい資料を参照するか確認する
現在有効な研修時間を答えてください。
根拠にしたファイル名と該当箇所を示してください。期待する回答は、90分です。
旧版の3時間を回答した場合は失敗です。
現在の要件と旧版を区別できるか確認する
過去に検討した研修時間案と、現在有効な案を分けて示してください。旧案の存在を説明することと、現在の要件として採用することを分けられるか確認します。
廃止した決定を推奨へ混ぜないか確認する
現在採用している研修形式を説明してください。
廃止済みの案を推奨へ混ぜないでください。未確認事項を、もっともらしい推測で埋めないか確認する
研修後の相談会の開催頻度を答えてください。未決定なら、
現在の正式資料では確認できない
と回答すべきです。
回答だけでなく、参照したファイルと箇所を確認する
回答が正しくても、旧版から偶然同じ数値を拾っているなら、将来の更新時に問題が起きます。
質問：
期待する回答：
参照すべき資料：
参照してはいけない資料：
実際の回答：
実際の参照元：
判定：
PASS / PARTIAL / FAIL / NOT FOUND
修正内容：重要な更新や構造変更の後は、取得テストをやり直す
正式要件を変更した
旧版を追加した
資料構成を変えた
新しい担当者を追加した
検索方式を変えた
公開・本番利用へ進む
といったタイミングで再確認します。
共有・権限・機密性もコンテキスト設計へ含める
案件コンテキストには、顧客情報、契約、未公開企画、個人情報が含まれる場合があります。
「AIが参照できるか」だけでなく、「誰が参照・更新できるか」も設計します。
誰が読めるかを情報ごとに決める
案件メンバー全員
管理職だけ
経営者だけ
外部委託先も含む
AIへは入力しない
正式資料を編集できる人を限定する
全員が正式要件を変更できると、最新版の信頼性が下がります。
閲覧者
編集者
承認者
を分けます。
下書きから正式版へ昇格する承認フローを決める
DRAFT → REVIEW → APPROVEDProjectへ追加してはいけない情報を決める
認証情報
不要な個人情報
顧客秘密
他案件の機密資料
利用権限のない著作物
外部共有できない契約情報
外部共有時に匿名化・削除する項目を決める
情報：
機密区分：
閲覧者：
編集者：
承認者：
外部共有：
保存期限：
削除条件：コンテキストは追加し続けるより、整理・削除・圧縮する
案件が長期化すると、資料は増え続けます。
しかし、資料量を増やすだけでは、コンテキスト品質は下がる場合があります。
旧版は通常の参照領域からarchiveへ移す
現在の作業で参照する必要がないなら、通常の検索対象から外します。
会話履歴から、正式決定と重要理由だけを抽出する
長いチャット履歴をすべて上位文脈として残す代わりに、
何を検討したか
何を決めたか
何を廃止したか
なぜ決めたか
を決定ログへまとめます。
重複する正式情報を一つの更新元へ統合する
同じ要件が複数ファイルへ少しずつ書かれていると、更新漏れが起きます。
現在の段階で不要なルールは上位指示から外す
企画段階だけで使った一時条件を、運用段階まで残し続けないようにします。
料金・仕様・法令などには再確認日を付ける
案件の段階が変われば、上位へ置く文脈も変える
企画段階では競合調査や仮説が重要です。
制作段階では確定要件、素材、品質基準が重要になります。
運用段階では実績、例外、変更履歴が重要です。
確認日：
追加した資料：
更新した資料：
廃止した資料：
削除した資料：
要約した履歴：
現在の正式版：
重大な未解決事項：
次回確認日：営業部向けAI研修を、毎回説明する状態からコンテキストパックへ変える
ここまでの設計を、一つの案件へ当てはめます。
題材は、これまでのフェーズでも扱った営業部向けAI研修です。
案件は、企画、実証、改善、全社展開の判断まで続きます。
最初は、各チャットで同じ条件を説明している
対象は営業担当20名
AI経験はほぼない
研修はオンライン90分
利用可能ツールはChatGPT
顧客情報は演習へ使わない
対象業務はメール、要約、商談準備
小規模実証後に全社展開を判断する
調査、教材制作、FAQ、実証分析を別チャットで行うと、条件が抜け始めます。
長期化すると、過去の廃止案が戻ってくる
3時間の対面研修
全社員一律研修
顧客メールを使う実践演習
AIツールを複数使う構成
これらが廃止済みでも、過去チャットや旧資料に残っていれば、新しい回答へ混ざる可能性があります。
実証結果を会話履歴から正式資料へ昇格させる
研修を10名で実証し、次が分かったとします。
メール作成は定着した
要約は元資料確認が不足した
商談準備は利用方法が曖昧だった
管理職のフォローが必要だった
これを`05_実証結果.md`へ記録し、次の教材改善と展開判断の正式根拠にします。
案件コンテキストパックを作る
00_案件概要.md
01_現在の状態.md
02_正式要件.md
03_AI利用ルール.md
04_決定ログ.md
05_実証結果.md
06_未解決事項.md
07_教材最新版.md
08_品質基準.md
09_成果物一覧.md
10_更新履歴.md
references/
archive/新しいチャットで取得テストを行う
確認する質問です。
現在の研修時間は何分か
顧客メールを演習に使えるか
廃止済みの案は何か
実証で最大の課題は何だったか
次に誰が何を判断するか
研修後の相談会頻度は確定しているか
未確定事項には「未確定」と答えられる必要があります。
取得に失敗した場合は、資料を増やす前に原因を切り分ける
正式資料が存在しない
最新版の表示が曖昧
旧版が通常検索へ混ざっている
資料名や本文が検索しにくい
重要条件が画像内にしかない
質問が曖昧
プロジェクト指示が競合している
AIが一般知識で補っている
原因に応じて、配置、表現、状態、指示を修正します。
案件コンテキストの完成は、情報量ではなく再現性で判断する
ファイルが大量にあることは、完成条件ではありません。
次の状態を再現できるか確認します。
案件の目的
現在の段階
正式要件
最新成果物
過去の決定
未解決事項
禁止事項
次の行動
「AIが覚えていた」ではなく、正しい根拠を使えたか確認する
再開時間・説明時間・修正回数を測る
導入前：
案件説明 25分
前提修正 4回
旧版混入 月3件
導入後：
案件説明 5分
前提修正 1回
旧版混入 0件別担当者でも同じ状態を再現できるか確認する
作成者本人だけがファイルの位置を理解していても、引き継ぎ可能とは言えません。
現場で使える案件コンテキスト設計テンプレート
案件境界
案件名：
目的：
対象：
開始日：
責任者：
関係者：
含む範囲：
含まない範囲：
関連案件：
共有範囲：
終了条件：案件概要
案件名：
目的：
対象者：
読後・利用後の変化：
中心命題：
現在の段階：
最優先事項：
正式な参照元：
主要成果物：
完成条件：
必須ルール：
禁止事項：
人間承認が必要な箇所：
詳細ルールの参照先：決定ログ
決定ID：
決定日：
決定事項：
状態：
決定者：
根拠：
前提：
採用理由：
不採用案：
不採用理由：
影響する資料・成果物：
見直し条件：
見直し日：未解決事項台帳
項目ID：
内容：
種別：
重要度：
結論への影響：
現在の仮定：
必要な確認：
確認担当：
期限：
解決後の反映先：
状態：コンテキスト取得テスト
質問：
期待する回答：
参照すべき資料：
参照してはいけない資料：
実際の回答：
実際の参照元：
判定：
PASS / PARTIAL / FAIL / NOT FOUND
修正内容：メンテナンス記録
確認日：
追加した資料：
更新した資料：
廃止した資料：
削除した資料：
要約した履歴：
現在の正式版：
重大な未解決事項：
次回確認日：フェーズ7へ到達したかを確認する
次の状態なら、フェーズ7の主要能力を実務で使えています。
案件の境界を説明できる
情報を普遍・案件・作業・履歴へ分類できる
案件概要と上位ルールがある
正式版・参考・旧版・未確定を区別できる
決定ログと未解決事項台帳がある
AIが正しい資料を取得できるかテストしている
権限と機密性を管理できる
定期的に情報を整理・削除できる
新しい担当者・チャットへ案件を引き継げる
同じ品質で作業を再開できる
過去チャットへ依存せず、現在の状態を説明できる
情報が見つからない場合に、推測ではなく未確認と判断できる
フェーズ7の目的は、AIへすべてを記憶させることではありません。
案件の正しい状態を、誰が・いつ再開しても再現できるようにすることです。
フェーズ8へ進む目安は、案件知識を手順として再現できること
フェーズ7では、AIが案件の背景、正式資料、過去判断、未解決事項を参照できるようになりました。
しかし、同じ情報を参照しても、担当者ごとに作業の進め方が違えば、成果物の品質は安定しません。
次のフェーズ8では、
何を入力するか
どの順番で作業するか
どのテンプレートを使うか
どこで人間が確認するか
例外時にどう対応するか
何を満たせば完了か
を標準化します。
案件知識を参照できる状態から、繰り返し業務を同じ品質で半自動実行できる状態へ進みます。
関連記事
プロンプト単体から、コンテキスト、ツール、状態、評価を含む設計へ対象が広がった流れを整理しています。
AIとのやり取りや修正を、その場限りで終わらせず、テンプレート、ルール、テスト、組織知へ変える方法を扱っています。
ChatGPTがチャットだけでなく、ファイル、アプリ、資料、コードを横断する仕事の環境へ変化している全体像を扱っています。
AI活用成熟度12フェーズ
出典・参考資料
OpenAI, “Projects in ChatGPT”
https://help.openai.com/ja-jp/articles/10169521-projects-in-chatgptAnthropic, “What are projects?”
https://support.anthropic.com/en/articles/9517075-what-are-projectsAnthropic, “How can I create and manage projects?”
https://support.anthropic.com/en/articles/9519177-how-can-i-create-and-manage-projectsAnthropic, “Retrieval augmented generation for projects”
https://support.anthropic.com/en/articles/11473015-retrieval-augmented-generation-rag-for-projectsGoogle AI for Developers, “Long context”
https://ai.google.dev/gemini-api/docs/long-contextGoogle AI for Developers, “Context caching”
https://ai.google.dev/gemini-api/docs/caching
