はじめに
AIにポートフォリオや学習のレビューを頼んでいると、すぐにぶつかる問題があります。
それは、AIが「今の自分の状態」を安定して引き継げないことです。
同じチャットを使い続ければ過去の文脈は残りますが、そのぶん会話が重くなります。
一方で、チャットを切り替えると、過去に決めたこと・現在の進捗・未確定の論点が飛びやすくなります。
私も、ポートフォリオ作成を進める中でこの問題に何度も困りました。
単発のレビューや質問応答はできても、「今どこまで進んでいて、何が決まっていて、次に何をやるべきか」を踏まえて伴走してもらうのは意外と難しかったです。
そこで、ChatGPTのProjects機能をベースに、
- 現在地を残すファイル
- 設計判断を残すファイル
- コードベース全体を共有する仕組み
- それらをいつ・何の目的で参照するかを縛る指示
をまとめて用意し、AIを単発の相談相手ではなく、継続的なメンターに近づける運用を作りました。
この記事では、そのために実際に使っている
- ファイル設計
- プロンプト設計
- 日々の運用フロー
をまとめて紹介します。
記事の最後に、実際に使っているプロンプト群を置いたGitHubも載せています。
そのまま真似するというより、自分用にどう分解・再設計するかの参考として見てもらえればと思います。
この記事で伝えたいこと
先に結論を書くと、やっていることはシンプルです。
AIに長期伴走してほしいなら、「記憶してほしい内容」をチャット履歴任せにせず、ファイルとして固定化するべきです。
そのうえで、
- 何を記録するか
- いつ更新するか
- AIがどの場面で何を参照するか
をセットで設計すると、AIの返答品質がかなり安定します。
つまり、必要なのは単なる長い万能プロンプトではありません。
ファイル設計 + プロンプト設計 + 運用フローの3点セットです。
どんな問題があったのか
普通のチャットだけでは足りなかった
AIは、同じチャット内であれば過去のやり取りを踏まえて答えてくれます。
ただ、レビューや壁打ちを何度も続けると、どうしてもチャットが長くなります。
私の場合、AIを「答えをすぐ出す人」ではなく「メンター兼レビュアー」として使っているため、
- 問い返し
- 自分の案のレビュー
- ダメ出し
- 修正後の再レビュー
を何度も繰り返します。
すると、1つのチャットに文脈を集め続ける運用は重くなりやすく、どこかで区切って新しいチャットに移る必要がありました。
しかし、チャットを切ると別の問題が出ます。
新しいチャットでは、過去に決めたことや未確定論点が十分に引き継がれないことです。
Projects機能だけに頼るのも不安定だった
では、ChatGPTのProjects機能を使えば解決するのかというと、私の体感では半分正解で、半分不足でした。
Projects機能では、同じProject内の別チャットもある程度は踏まえてくれます。
ただし、毎回こちらが期待する粒度で、過去の判断や進捗が完全再現されるわけではありません。
たとえば、
- 以前は「未確定」だった論点を、既定事項のように扱う
- 過去に採った設計方針を拾い切れない
- 進捗を最新ではなく途中状態で理解して返す
といったズレが起きることがあります。
なので、Project機能は便利ですが、「重要な背景を必ず思い出してくれる仕組み」ではないと考えた方が安全でした。
解決策の全体像
そこで作ったのが、次の3層で回す仕組みです。
1. ファイル設計
AIに覚えておいてほしい内容を、用途別のファイルに分けて保存する。
2. プロンプト設計
AIが「どの立場で」「何を優先し」「どのファイルをいつ参照するか」をProject指示で縛る。
3. 運用フロー
チャットをどの単位で区切り、区切りごとにどのファイルを更新するかを決める。
この3つを組み合わせることで、はじめて
**「背景を踏まえて継続レビューするAI」**に近づきました。
用意しているもの
最低限、私が用意・使用しているのは次のものです。
- ChatGPTのProjects機能
- 各種ドキュメント
- Googleドキュメント
- VSCode
- Repomix
なぜClaude CodeやClaude.aiではなくChatGPT Projectsにしたのか
結論だけ先に言うと、今回は「継続的な学習メンター用途」と「他の用途での利用枠」を分けたかったからです。
Claude Codeは、ローカルのファイルを前提にしながら作業させるにはかなり強いです。
コードレビューや文書整理もできます。実際、私も別用途ではかなり使っています。
ただ、学習の壁打ちやレビューまでClaude側に寄せると、参照ファイルや過去文脈が増えるぶん、利用枠をかなり消費しやすいと感じました。
私はClaude Codeを記事執筆やミニアプリ作成でも使っているため、学習の対話で利用枠を削りたくなかったのが大きいです。
また、claude.aiにもProject機能はありますが、claude.aiとClaude Codeは利用枠を共有しているため、同様に利用枠を削りたくなく、選択しませんでした。
プロンプト設計でやっていること
このProjectで一番大きいポイントは、
AIに「何を知っておくべきか」だけでなく、「いつ・何を参照し・どの立場で返すか」まで設計していることです。
単にファイルを置いただけでは、AIは毎回その場の相談文を主軸に返しがちです。
逆に、プロンプトだけを頑張っても、私の学習状況や過去の判断のコンテクストは入りません。
そこで、私は
- Project自体の中核指示
- 目的別の補助プロンプト群
- 進捗や設計判断を残すドキュメント群
を分けています。
Project自体に設定している指示
Projectの指示では、ChatGPTを単なる回答役ではなく、シニア開発メンター兼レビュアーとして振る舞わせています。
具体的には、いきなり完成コードや完成設計を出すのではなく、まず
- 問題の再定義
- 前提・制約の確認
- 考えるべき観点の整理
- 自分の案へのレビュー
- 必要なら最小限のヒントや部分例
を優先させています。
さらに、相談内容に応じてどのファイルを優先して参照するかも指示しています。
たとえば、私のProjectでは概ねこうしています。
- 日々の相談 → 現在の学習フェーズ定義 + 学習ログ
- レビュー依頼 → レビュー観点チェックリスト
- テーマ別の判断 → テーマ別指導方針
- ADR判断 → ADRインデックス
つまり、AIの返し方だけでなく、参照先まで先回りして縛っているわけです。
補助プロンプト群
補助プロンプト群の目的は、長い万能プロンプトを1本作ることではありません。
用途ごとに役割を分けることです。
私が使っている例は、以下のようなものです。
| ファイル名 | 役割 |
|---|---|
01_テーマ別指導方針.md |
DB設計・API設計・実装・テストなど、テーマごとにAIが見る観点を定義 |
02_相談テンプレート.md |
相談文の品質を上げるための型 |
03_レビュー観点チェックリスト.md |
レビュー時に優先して見る観点の整理 |
04_フェーズ1専用学習対象定義.md |
今のフェーズで何を優先し、何をまだ主対象にしないかを固定 |
05_ADRインデックス.md |
どんな判断をADRとして残すべきかを整理 |
※「04_フェーズ1専用学習対象定義.md」「05_ADRインデックス.md」は完全に私向けの資料ですが、参考までに書いています。
ここで大事なのは、最初から完璧な構成を作ろうとしないことです。
私も最初からこれだけ揃っていたわけではありません。
実際には、使いながら
- 不満が出たら足す
- 重複したら統合する
- 中核指示に寄せた方がよいものはProject指示へ移す
という形で何度も組み替えています。
ドキュメント設計でやっていること
プロンプトでAIの振る舞いを縛っても、
「今の自分の状態」を伝えるファイルがなければ意味がありません。
このProjectでは、主に次の4種類のファイルを資源として格納しています。
| ドキュメント | 役割 | 更新タイミング |
|---|---|---|
学習ログ_累積 |
学習状況、理解したこと、詰まったこと、次にやることを記録 | 目的単位のチャットが一段落したとき |
| ADR | 設計判断の理由、比較した案、不採用案、見直し条件を記録 | 設計方針が固まったとき |
| Repomix | コード・README・ER図などを含む現時点の設計状態を共有 | 成果物が更新されたとき |
学習ロードマップ |
学習全体の優先順位と進行方針を固定 | フェーズ移行や方針変更時 |
この4つを、それぞれ別の目的で使っています。
1. 学習ログ_累積
これは、今の学習状況を残すためのファイルです。
たとえば、
- 今回やったこと
- 何を理解したか
- まだ曖昧なこと
- 自分で決めたこと
- 次にやること
- 次回AIに相談したいこと
などを残します。
重要なのは、きれいな文章を書くことではなく、
次のチャットに移ったときに、自分とAIの両方が現在地を再開できることです。
2. ADR
ADRは、「なぜその設計を採ったのか」を残すためのファイルです。
ポートフォリオを作っていると、どうしても「今はこうしているけど、なぜそうしたのか」が埋もれます。
なので、たとえば
- なぜ題材をTodoではなく申請・承認にしたか
- なぜ監査ログを独立概念として持つのか
- なぜRBACをこう切ったのか
といった論点は、READMEではなくADRに整理しています。
3. Repomix
Repomixは、その時点のコードベース全体をAIに共有しやすくするための仕組みです。
参考：https://repomix.com/ja/guide/
README、docs、ER図、設定ファイル、ソースコードなどが分散していると、AIに毎回それぞれ説明するのは大変です。
そこで、リポジトリ全体を1ファイルにまとめたものをProjectに渡しています。
これによってAIが
- 現在の設計状態
- ディレクトリ構成
- 既存のADRやER図
- READMEの内容
をまとめて参照しやすくなります。
もちろん万能ではありませんが、「毎回全部貼る」よりは圧倒的にマシです。
4. 学習ロードマップ
これは、全体の方角を固定するためのファイルです。
日々のチャットだけで進めていると、その場の疑問や細部の修正に引っ張られやすくなります。
すると、今本当に優先すべきことがぶれます。
そこで、
- 今のフェーズでやること
- まだ主対象にしないこと
- 学習順序
- ゴール条件
をロードマップとして固定しています。
自分に最適化した学習ロードマップの作成方法は過去記事で紹介しているので是非ご覧ください。
ChatGPTで自分に最適化された学習ロードマップを設計する方法
この仕組みのポイント
ここまでを一言でまとめると、このProjectでAIに渡しているのは、次の3つです。
- 現在地 → 学習ログ
- 現物 → Repomix
- 方角 → 学習ロードマップ
- 判断理由 → ADR
これに、AIの振る舞いを縛る指示を組み合わせています。
だからこそ、単発のQ&Aではなく、継続的な伴走に近い動きになります。
1サイクルの実際の運用フロー
この仕組みはファイルを置いただけでは回りません。
重要なのはどの単位でチャットを切り、切れ目で何を更新するかです。
私が今やっている1サイクルは、おおむね次の流れです。
- 今日の目的を決める
- その目的だけに絞った新規チャットを作る
- 相談テンプレートに沿って、自分の理解や案を書く
- AIと壁打ち・レビューを進める
- 一段落したら、学習ログに現在地を残す
- 設計判断が固まったらADRに切り出す
- 成果物が変わったらRepomixを更新する
- 必要なら次のテーマ用に新しいチャットへ移る
この流れにしている理由は、1つのチャットに全部を詰め込まないためです。
チャットはあくまで「その回の作業場所」であって、
長期的に残したい情報はチャットではなくファイルに移します。
実例：ER図検討をどう回していたか
たとえば、ER図を検討していたときは、
- 概念ER図
- 論理ER図
- 物理ER図
をそれぞれ別チャット・別区切りで進めました。
各チャットではその場のレビューに集中し、一段落したところで
- 何を理解したか
- 何が未確定か
- どの判断を採ったか
- READMEやADRに何を残すべきか
を学習ログに反映します。
さらに、
- 参照方式
- 版管理方式
- 監査ログの扱い
のように、後から説明が必要になる判断はADRとして独立させます。
そして、図やdocsやREADMEが更新されたタイミングでRepomixを作り直して、Project側の共有状態も更新します。
この流れにしておくと、次のチャットでAIに相談するときも
「前回何を決めたか」「まだ何が未確定か」をかなり短い説明で再開しやすくなります。
この運用にして良かったこと
1. AIの返答が安定しやすくなった
一番大きい効果はこれです。
毎回チャット履歴だけに頼るよりも、ファイルに整理した前提を参照させた方が、返答のブレが減りました。
2. 自分自身の整理にも効いた
これは予想以上でした。
AIのために作った仕組みですが、実際には自分のための整理装置にもなっています。
特に、
- 何が決定済みか
- 何が未確定か
- どこで詰まったか
- 次にどこへ進むか
が見えやすくなります。
3. 人への説明やREADMEで使える材料が溜まりやすい
ADRや学習ログを残していると、後で「なぜその設計にしたのか」を説明しやすくなります。
これは単に開発を進めやすくするだけでなく、
成果物を説明用に整理するという意味でもかなり大きいです。
逆に、この仕組みの弱点
もちろん、これで全部解決するわけではありません。
1. 更新の手間はある
ファイルに固定化する以上、更新作業は必要です。完全自動ではありません。
ただ、これはコストというより、
「重要な判断を自分でも言語化するための工程」 だと割り切っています。
2. 最初から完璧には設計できない
どのファイルを分けるべきか、どこまでProject指示に入れるべきかは、使いながらでないと分かりません。
なので、最初から完成形を目指すより、不満が出た箇所だけ少しずつ切り出す方が現実的です。
3. AIの精度が100%保証されるわけではない
ファイルを置いても、AIが毎回完璧に読んで完璧に使うわけではありません。
結局、最終的な判断は自分が持つ必要があります。
ただ、それでも
「何も固定化していない状態」よりはかなり再現性が上がる
というのが今の実感です。
これから作る人向けの最小構成
もしこれから似た仕組みを作るなら、最初は全部やらなくていいと思います。
まずは次の最小構成で十分です。
最低限あるとよいもの
- 学習ログ_累積
- レビュー観点チェックリスト
- 相談テンプレート
- 学習ロードマップ
- Repomixファイル
最初に決めておくとよいルール
- チャットをどの単位で切るか
- チャット終了時に何をログへ残すか
- どんな判断をADR化するか
- AIにどの立場で返してほしいか
このあたりが揃うだけでも、単発チャット運用よりかなり安定します。
おわりに
実際に使っているプロンプト群や、運用の元になっているファイル群は以下に置いています。参考までにどうぞ。