AIとアプリを作り始めた時にとりあえず作りたいものを伝えて、なんとなく作ってみたりしてませんか。
私も初めの頃は、一つのチャットで作りたいものを伝えて質問も実装も修正も続けていました。そうするとどうでしょう途中で伝えたことが抜けたり、なぜか話がかみ合わなくなったりして、なぜそうなったのか分からず、そのまま修正を頼んでいたんですよね。
そこから少しずつ、工程を分けることを覚え、次のチャットへ渡す内容を資料にまとめるようになりました。するとどうでしょう、結構しっかりとものが出来上がるようになってきたではありませんか。
その経緯は「AIとの開発で一番変えたことは、一つのチャットで作り続けないことだった」に書きました。今回はもう少し具体的に、今のサーバー資料を例にして、中身を紹介してみます。
サーバーの話を、全部一つの資料に詰め込まない
今の自宅サーバーには、ローカルAIを動かす環境に加えて、日々のメモを残すLifeLogや、PCの音を集めてスピーカーへ出す仕組みも入っています。
どれも同じサーバーの話ではあるんですが、文字起こしをする機能を直したいときと、スピーカーから音が出ないときでは、見るべきところが違います。名前に「音声」が付いているだけで、話を混ぜるとややこしいんですね。
2026年9月26日時点では、構成の資料を次の4つに分けています。
| 資料 | 中に書いていること |
|---|---|
| AI推論基盤・Hermes開発環境 | モデル、文字起こし、開発用AIを動かす環境 |
| LifeLog | メモや写真の保存、音声で一日を振り返る仕組み |
| PC音声転送 | 複数のPCの再生音を、サーバーにつないだスピーカーへ送る経路 |
| 共通運用基盤 | 接続、権限、更新、NASへのバックアップなど |
ただ、分けたら完全に別々になるわけでもありません。例えばLifeLogはAI推論基盤のモデルを使います。LifeLogだけ読めば何でも分かるという形にはせず、関係する資料へ進めるようにしています。
「今どうなっているか」と「まだ確かめていないこと」を分ける
各領域には、構成を説明する引き継ぎ資料、操作を説明する運用手順書、それから残課題を置いています。
引き継ぎ資料には、今どんな仕組みで動かしているかをまとめてもらって何か変更を加えたいとき、追加をしたい時などにAIが参照する資料として使っています。運用手順書には、普段どう操作し、どこを確認するか、主に私自身が確認し、日々利用する資料としています。残課題には、各環境を作った時にAI自身がまだ確認していないと思った点や、まだ実装していない検討中の仕様などを次の作業のために残しておく資料になっています。
実際の内容から、接続先などを省いて短くすると、こんな感じになります。以下は原文そのままの引用ではなく、公開用に整理した例です。
【現在の構成】
LLMは原則1モデルずつ読み込む。
文字起こしは別サービスで常駐させる。
実装用と日常用など、用途に応じたモデルの役割を用意している。
【操作・確認方法】
モデルを切り替える操作と、稼働状態の確認方法は運用手順書を見る。
役割を選んだだけで、次の担当へ自動で作業が渡るわけではない。
【まだ確認すること】
要件整理・設計用モデルの実案件での品質。
長い入力や会話での品質と安定性。まだ確認することなどはAIが資料作成時にこういうのも確認しておいた方がいいだろうと追加したものだったりするので、個人的には結構冗長な確認だなと思ったりしてます。
補足で、ChatGPTに限った話ではないのかもしれませんが、結構AIに作業をさせると個人で使用するレベルでは過剰な確認をしたりするのでレートリミットが低いプランなどで作業させていると確認だけで枠を使い切ってしまったりするのが難しいところですね。
課題のような資料は別枠で用意しておいた方がよさそうかなと個人的には思っています。色々な構成情報を含んだ資料の中にポツンと課題が一つだけ残っていたりすると正常に読まれなかったり、変に読まれたりして急に課題を対応し始めたりするのでファイル分けやフォルダ分けはなるべくするようにしています。
次の工程で見てほしいものを、ファイルで渡す
サーバーを管理する資料とは別に、ローカルAIで開発を進めるための資料の置き方も一応決めています。というかこの運用も実際にはAIに考えてもらいました。
project/
├─ docs/
│ ├─ requirements/requirements.md … 作りたいものと条件
│ ├─ basic-design/basic-design.md … 基本設計
│ ├─ test/test-plan.md … 確認する内容
│ ├─ implementation/tasks.md … 実装する作業
│ └─ review/ … 各工程の確認結果
├─ decisions/ … 判断したことと理由
├─ src/ … プログラム
└─ tests/ … テストここまで実際には厳密ではないですが、ある程度工程ごとのフォルダ分けを意識して開発を進めるようにはしています。ただ、簡単なアプリケーションとかは普通に一つのチャットでフォルダ分け意識せず作ったりするのでその場のノリだったりしますが・・・。
一応、工程を分けて、次の工程に進む時は、新しいチャットを用意して、コンテキストを分けて、前工程のファイルを渡して、次の工程説明と作業フォルダを渡して作業をしてもらうっていうのを今は手作業でやってる感じですね。Hermes Agentとか使っていたら、カンバンとか使って作業フローを作れるのかもしれませんが、そういうのはまだ勉強中なので完全に力技で実装していっています（笑）
引き継ぐときは、今回頼む範囲も添える
さっき少し話しましたが、次の工程に移る時は、対象のプロジェクトフォルダ、入力になるファイル、どこまで作業してほしいか、勝手に先へ進めないことを指定する方針にしています。
巷では、止まらないAIエージェントが望まれているというか業界的にそっちの方向に進んでいるような雰囲気は感じますが、途中で方向転換させるときにAIの思考が一気に下がってすごく混乱して無茶苦茶なことをし始めるというのを体験しているので、一気通貫で作業させるのは絶対にやらない方針にしています。
例えば、設計がまとまって「実装する作業を分けてほしい」という段階なら、タスク分解を一つのチャットで実施させます。そして、1タスクあたり1ファイルに作業を分割してもらってから、そのファイルを別のチャットで読み込ませ全体像を理解させてから、バイブコーディングをするので、別のチャットに指示する文章を生成してと頼んで、生成した指示文をまた別のチャットに送る、結果が返ってきたらそれを指示元のチャットに返してということを繰り返してなるべく作業する時はクリーンな状態で作業してもらうようにしています。
この方法で作業すると途中で実装を変えたいときや、実装に躓いた時、途中で作業を区切りたいときに気持ち的に楽なのでそうしています。ChatGPTだとこういうのはサブエージェントをしっかり使ってコントロールをしっかりするぐらい賢いとは思うのですが、ローカルAIモデルだとまだ賢さが足りないので、人力サブエージェントで頑張っているという感じでしょうか。
確認していないところは、次へ残す
引き継ぐ資料には、できたものだけでなく、確認した結果と残っていることも入れます。というか大体のモデルは勝手にここら辺は入れてくる印象です。
ローカルAIの開発手順では、作成した資料精度が低いことがあります。そのため、自信満々に作成できました！と返ってきてもChatGPTの高位モデルにレビューさせたらほぼ書き直しじゃね？ってぐらい指摘事項が出てきます。なのでなるべくわからなかったところとか、仮の想定など色々書かせて、その後別のモデルでブラッシュアップや指摘修正をしやすくしているという感じです。
ローカルAIでの開発はまだまだ研究途中なので、今はChatGPTのレートリミットを使い切らないように少しずつ、ChatGPTでなくてもできる作業を任せていっているというところですね。
それでも、一つのチャットで延々と修正していた頃より、次にどの資料を見て、何を頼むかみたいなプロジェクト全体の把握はしやすくなったかなと思います。気休めかもしれませんが私には、この違いが結構大きかったという情報共有でした。
コメント