案件で得た知見を「資産」に変え、次の案件の初速を上げる

AIの技術は数か月で入れ替わる。個人の努力だけで追いかけると、知識は人に属し、組織はその人が押さえている範囲でしか動けない。本格的な事業開始から約3年で正社員約60名の体制になるなかで、私たちが大事にしてきたのは、案件で得た知見を再利用できる「形」にし、次の案件に再投入する仕組みだ。

この記事の要点

• 生成AIの案件は一つとして同じものがないように見えるが、評価・知識の切り分け・運用の型は再利用できる
• 知見は「資料」ではなく、評価セット、Skill、ルールファイルのように動かせる形で残す
• 自社で回している学習の循環を、そのまま顧客の組織にも残す

再利用できるのは、コードよりも「型」である

生成AIの案件は、業界も、データも、業務も違う。だが実際には、繰り返し現れるものが多い。帳票や図面の読み取り方。評価セットの作り方。精度が伸びないときの原因の切り分け方。現場に定着させるための運用の決め方。

非構造データが多い複雑な領域ほど、ユースケース、評価の指標、運用のプロセスは再利用できる。問題は、それが担当者の頭の中にしかないことだ。

1. 案件で解く：顧客の現場で課題を解く。
2. 形式知にする：勉強会・技術ブログで言語化する。
3. 社内基盤に組み込む：AI基盤・Skill・評価の型として残す。
4. 次の案件へ：共通の型を持ち込み、初速と精度を上げる。そこで得た知見を再び循環へ戻す。

この循環を顧客にも残すことが、内製化・自走の支援につながる。

案件で得た知見を言葉にし、社内基盤に組み込んで、次の案件に持ち込む。この一周が速いほど、組織全体の初速が上がる。

知見を「動かせる形」で残す

報告書や振り返り資料は、書いた瞬間から古くなる。読まれなければ、ないのと同じだ。私たちは知見を、次の案件でそのまま動かせる形で残すようにしている。

これらは、可能な限りコードと同じように版を管理する。変更の履歴が残り、誰が何を改善したかをたどれるからだ。

循環を回すための4つの仕組み

1. 論文ベースの社内勉強会。技術の言説にそのまま乗らないために、一次情報に当たる。「RAGは死んだ、は本当か？」をテーマにした回では、最新の論文4本をもとに、どの場面でどの検索方式が効くかを検証した。エンジニアとコンサルタント約20名が参加し、終了後も自分の案件の構成に当てはめた議論が続いた。Physical AIのように、まだ案件になっていない領域も扱う。

2. 失敗も含めて外に書く。技術ブログでは、うまくいかなかった試みも公開している。外に書く前提に立つと、推測と事実を分け、条件を書き、再現できる形にまとめるようになる。それ自体が、知見を形式知にする訓練になる。

3. ナレッジが社内にたまるAI基盤。個人がそれぞれAIツールを使うだけでは、プロンプトも工夫も個人の手元に残る。そこで社内専用のAI基盤を自分たちで作った。社員がAIエージェントを作り、育て、チームで共有できる。普段のチャットツールから呼び出せる。機密情報を扱えるよう、自前でホスティングするLLMも用意した。使うほど会社に知見がたまる形を目指している。

4. 使い方を可視化し、共有する。社内のAI利用状況をレポートにまとめ、全社に共有した。目的は個人の評価ではなく、活用事例を広げ、必要な環境や支援を把握することだ。エンジニアが普段どうAIと開発しているかも、社内で公開している。要件が曖昧なときはAIに質問させて仕様を固める。AIの「完了しました」は信じず、テストやログで確かめさせる。そうした流儀が、個人からチームへ広がっていく。

「使われるシステム」は、業務の側から生まれる

社内で学んだことがもう一つある。今ではエンジニア以外の社員も、生成AIで日々の業務を効率化している。自社で開発した社内システムも増えた。そのなかで使われ続けているのは、ビジネス側のメンバーが事業のKPIや課題を考え、それを形にする形で作られたものだ。技術から発想したものは、残りにくい。

これは、私たちが顧客に繰り返し伝えていることと同じだ。自社で実践して確かめたことだから、自信を持って勧められる。

自社で回しているものを、顧客にも残す

私たちのVisionには「支援をし続けない。自社で回せる状態を残す」という一文がある。顧客に残すべきなのは、完成したシステムだけではない。評価の仕組み、改善のサイクル、知識を更新する運用、そしてそれを回せる人だ。つまり、私たちが自社で回している学習の循環そのものである。

目指すのは、AIを使う会社ではなく、AIで学び続ける会社だ。そして、その形を顧客の組織にも残していく。