AI開発のナレッジ蓄積｜案件の学びを次に生かす仕組み
AI駆動開発では、案件が終わるたびに得た学びを次の開発へ引き継げるかどうかで、開発の安定感が変わっていきます。この記事では、AI開発におけるナレッジ蓄積とは何を指すのか、何を残して、どこに置き、どう更新するのかを順に整理します。あわせて、機密情報の扱いと、発注側が確かめておきたい点も取り上げます。
AI駆動開発でいう「知見をためる」とは何か
「ナレッジ蓄積」と聞くと、社内Wikiに議事録を貯めていく作業を思い浮かべる方が多いと思います。AI駆動開発での蓄積は、それとは少し性格が違います。人が読み返すための記録であると同時に、AIが次の作業で参照して使える形に整えておく、という役割を持つからです。
AIは前の案件の経緯を覚えていない
GPTやClaudeなどの大規模言語モデル（LLM）は、基本的に、いま渡された情報をもとに答えを組み立てます。多くの利用環境では、会話や作業のセッションが変わると、前の案件で何を決めたのかは引き継がれません。つまり、何も整えなければ、案件を重ねても学びは積み上がらず、毎回ゼロから始まるのと変わりません。
この性質を前提にすると、「AIに賢くなってもらう」のではなく、「次の作業でAIが読める情報を、こちらで育てておく」という考え方が基本になります。モデルの性能向上は提供元の進化に任せるしかありません。一方で、案件で得た判断基準や注意点を整理して手元に残す作業は、開発に携わる私たち自身の領分です。
人の記憶に頼る蓄積との違い
従来の開発でも、経験豊富なエンジニアの頭の中には多くの知見がありました。ただ、それは個人の記憶や勘に近い形で保たれていたため、担当者が変わると失われやすいという弱点があります。属人化の問題については、システム開発の属人化を防ぐ｜工程のフロー化とAI開発基盤でも触れています。
AI駆動開発では、知見を文章やルール、チェック項目といった形に書き出すこと自体が、AIを動かす材料になります。書き出された知見は、担当者が代わっても、AIにも新しいメンバーにも同じように渡せます。蓄積が人の外に出ていくため、属人化を抑えやすくなるのです。
何をためるか：残す価値のある5つの種類
案件で起きたことをすべて残そうとすると、量が増えすぎて、誰も読まない資料になります。AIに読ませる場合も、関係の薄い情報が混ざると、判断がぶれる原因になりかねません。そこで、次の案件で再利用できる種類に絞って考えます。
1. 要件を聞き出すときの型
新規事業のシステムでは、依頼を受けた時点で仕様が固まっていないことがよくあります。そのとき、どんな順番で、どんな質問をすると、作りたいものが具体的になるのか。この「聞き方の型」は、案件をまたいで使える知見です。
たとえば、利用者は誰か、最初に確かめたい仮説は何か、最初の版に入れないものは何か、といった問いの並べ方です。要件定義の整理でAIが担える範囲は、AI要件定義で変わること｜AIが整理し人が決める範囲で解説しています。
2. 設計の判断と、その理由
設計では、結論だけでなく、なぜそうしたのかを残すことが大切です。データの持ち方を選んだ理由や、外部サービスを使うか自作するかの判断理由が残っていれば、次に似た場面に出会ったときに、同じ検討をやり直さずに済みます。
結論だけが残ると、条件が違う案件にそのまま当てはめてしまう危険があります。理由が書かれていれば、「今回は前提が違うから別の選択をする」という判断もできます。設計書の残し方については、AI設計書の自動生成は可能？後から困らない残し方も参考になります。
3. レビューで指摘された点
コードレビューで繰り返し指摘される内容は、蓄積の価値が高い部分です。同じ種類の指摘が複数の案件で出るなら、その観点を最初からチェック項目に入れておけば、作る段階で防げます。
AIによるレビューで拾える点と、人が判断すべき点の分け方は、AIコードレビューで指摘される点と人が判断する点にまとめています。指摘の中身だけでなく、「これは人が判断した」という線引きも、あわせて残しておくと役に立ちます。
4. テストで見つかった不具合のパターン
テストで見つかった不具合は、次の案件のテスト観点になります。入力の境界値、権限ごとの表示の違い、通信が途切れたときの動きなどです。不具合そのものより、「どういう条件で起きたか」を一般化して残すのが要点です。
テストの自動生成で任せる範囲と人が見る項目は、AIのテスト自動生成｜任せる範囲と人が見る確認項目で整理しています。蓄積したパターンは、こうした自動生成の入力としても使えます。
5. もっともらしい誤りの傾向
生成AIは、事実と異なる内容を、もっともらしく出力することがあります。どんな場面で、どんな種類の誤りが混ざりやすかったのかを記録しておけば、確認すべき場所を先に絞り込めます。
誤りが混ざる仕組みと見つけ方は、生成AIのハルシネーションが開発に混ざるとき｜見つけ方と防ぎ方で解説しています。誤りの傾向は、モデルの更新で変わる場合があります。蓄積した内容には、いつ時点の記録かを添えておくと、後で見直しやすくなります。
どこに、どんな形で置くか
ためる内容が決まったら、次は置き方です。ここで工夫が足りないと、せっかくの知見が活用されません。
人にもAIにも読める形にする
置き方の基本は、文章を短く、条件と結論をはっきり分けて書くことです。長い経緯をそのまま貼るよりも、「どんな場面で」「何をすると」「どうなるので」「こうする」という形に整理したほうが、AIも人も使いやすくなります。
多くのAI開発ツールには、プロジェクトごとに守るべきルールや前提を、文書として読み込ませる仕組みがあります。そうした仕組みに、設計の方針、命名の決まり、確認項目などを置いておくと、作業のたびに同じ指示をし直さなくて済みます。ツールごとの違いは変わりやすいため、使うときは各提供元の公式ドキュメントで確認するのが確実です。
工程ごとに分けて持つ
要件、設計、データベース、実装、テスト、レビューでは、必要になる知見が違います。ひとまとめの大きな文書にしてしまうと、どの工程の作業でも全部を読むことになり、かえって精度が落ちる可能性があります。
そこで、工程ごとに分け、その工程の作業をするときだけ読む構成にします。AIに工程ごとの役割を持たせて進める考え方は、AI開発フレームワークとは｜LLMだけの開発との違いで説明しています。蓄積の置き場所も、この工程の分け方に合わせると整理しやすくなります。
古くなった知見を片づける
蓄積には、増やす作業と同じくらい、見直す作業が大切です。利用するライブラリの仕様変更や、AIモデルの更新によって、以前は正しかった注意点が当てはまらなくなることがあります。古い情報が残っていると、AIがそれを根拠に誤った判断をしてしまいます。
そのため、案件の終わりに「この知見は次も使えるか」「条件が変わっていないか」を確かめ、不要になったものは削除する運用が欠かせません。モデルの提供終了や入れ替えが起きたときの備えは、LLMモデル変更に備える開発の進め方｜提供終了の前にで取り上げています。
ためた知見を安全に生かすための注意点
知見をためて次に生かす、と言うと便利に聞こえます。しかし、扱い方を誤ると、別の問題を生みます。
お客様の情報を混ぜない
最も気をつけたいのは、案件固有の情報と、一般化できる知見を分けることです。ある案件の事業アイデア、顧客データ、独自の業務ルールが、別の案件の作業に紛れ込むことはあってはなりません。
蓄積に回してよいのは、「聞き方の型」「設計の判断基準」「レビューの観点」のように、特定のお客様の情報を取り除いても意味が通る内容です。お客様のアイデアそのものや、そこから特定できる情報は、蓄積の対象にしない線引きが必要です。機密の扱いは生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアで詳しく解説しています。発注するときは、秘密保持の取り決めとあわせて、こうした扱いを確認しておくと安心です。
蓄積した知見を「正しいもの」と決めつけない
蓄積した知見は、過去の案件ではうまくいった、という記録にすぎません。今回の案件にも通用するとは限りません。AIが蓄積を参照して出した提案でも、新しい案件の目的や制約に合っているかは、人が確かめる必要があります。
品質の最終判断を人が担う理由は、AI開発でも品質には人の確認が必要な理由で整理しています。蓄積が増えるほど、「前もこうだったから」という安心感に引っ張られやすくなります。だからこそ、判断の場面では、目の前の案件の条件に立ち返る姿勢が欠かせません。
蓄積の量を成果と取り違えない
文書の数や記録の量は、蓄積の質を表しません。読まれない文書や、矛盾した記述が増えるほど、AIの出力はぶれやすくなります。蓄積の良し悪しは、量ではなく、次の案件で実際に役立ったかどうかで見るのが妥当です。たとえば、同じ指摘が繰り返されなくなったか、要件を聞き出す手間が減ったか、といった点です。
発注側が確かめておきたいこと
知見の蓄積は、開発会社の内側の話に見えます。ただ、発注する側にとっても、確かめておく価値のある点がいくつかあります。AI受託開発に依頼する前の全体的な確認事項は、AI受託開発に依頼する前に確かめたい6つのことにまとめています。ここでは蓄積に絞って挙げます。
- 知見がどんな形で保たれているか：担当者の経験だけに頼っているのか、工程ごとに整理された仕組みとして持っているのかを、質問して確かめます。
- 案件の情報の扱い：自社の事業アイデアやデータが、他の案件の作業に使われないことを、取り決めや説明で確認します。
- 更新の仕組みがあるか：古くなった知見を見直す流れがあるか、AIモデルが変わったときにどう対応するかを聞いておきます。
- 人が判断する範囲：何を作るかを決める部分と、品質の最終判断を、誰が担うのかが明確かを確かめます。
- 納品後に何が残るか：設計の理由や判断の記録が、納品物として手元に残るかどうかを確認します。納品物の考え方はシステム開発の納品物一覧｜ソースコード以外に受け取る成果物が参考になります。
蓄積の仕組みは、見た目では分かりにくい部分です。だからこそ、「どう残し、どう更新し、どこまで人が判断するのか」を言葉で説明してもらえるかが、一つの目安になります。AI駆動開発全体の役割分担は、AI駆動開発とは｜AIと人の役割分担と発注側の要点で整理しています。
まとめ
AI駆動開発で知見を生かすには、AIが前の案件を覚えていないことを前提に、次の作業で読める形に学びを整えておく必要があります。ここまでの要点は次のとおりです。
- ためる対象は、要件の聞き方、設計の判断と理由、レビューの観点、不具合のパターン、誤りの傾向の5種類に絞ると扱いやすくなります。
- 置き場所は、人にもAIにも読める短い文章にして、工程ごとに分けます。古くなった知見は、案件の終わりに見直して片づけます。
- お客様固有の情報は蓄積に混ぜず、一般化できる知見だけを残します。蓄積した内容も、新しい案件の条件に照らして人が確かめます。
- 発注側は、知見の持ち方、情報の扱い、更新の仕組み、人の判断範囲を、開発会社に質問して確かめます。
JustFitを運営する株式会社LEGAREAは、AIを活用した独自の開発基盤「LAF（LEGAREA AI Framework）」を使っています。LAFでは、要件定義・設計・DB設計・実装・テスト・レビューの専門AIがチームとして開発を進め、案件を終えるたびに知見が加わることでフレームワーク自体が進化し続けます。人の役割は、何を作るかを決めることと、品質の最終判断です。新規事業のシステムを、動くプロトタイプで確かめながら進めたい場合は、JustFitのサービス紹介もご覧ください。