AIのモデルに依存しない、シゴデキAIのつくり方

AIに仕事を頼んで、返ってきたものを直す。
その修正や判断を次AIに依頼する仕事にも引き継げれば、同じ説明を繰り返さずに済みます。

私は、ClaudeのチャットからコマンドでAIを呼び出して社内の資料や議事録について質問したり、Claude CodeやCodexのAIエージェントに手順書に沿って文章作成や社内ツールの開発を進めてもらったりしています。

作業中の修正や質問は自動で記録し、次の作業でAIが読み込めるようにしています。
以前のコラムでは、この記録を次の仕事に生かす仕組みについて書きました。

関連記事：「使うたびに賢くなるAI」は、待っていても来ない

今回は、その仕組みを使いながら、AIが仕事を進めやすい環境をどう整えてきたかという話です。

AIのモデル自体を調整するファインチューニング等は行っておらず、AIに渡す情報、作業の手順、成果物の確認方法を整えることで、同じ説明や手直しを繰り返す手間を減らす工夫をしてきました。

今回は、その取り組みと、途中つまずいたことを紹介します。

同じ修正を繰り返さないために

私は、提案書や資料づくり、社内ツールの開発、そしてこのコラムの執筆など、様々な業務でAIを活用しています。

業務のほとんどを一緒に進めていますが、AIが最初から私の好みや判断基準を理解しているわけではありません。

例えば、このコラム作成という業務でも、始めは生成された文章から、社内の細かい数字などを何度も削りました。
生成された文章でよくある「ここが大事です」のような言い回しも、何箇所も修正しました。

そこで、私がどこをどう修正し、なぜ修正したのかをルールとして残し、次の記事を書き始める前にAIに確認させるようにしました。

その結果、今では初稿から細かい数字を控えた原稿が出てきますし、禁止した言い回しも使われなくなりました。

そして大事なのは、この修正内容を残しておくという工程さえも仕組み化しておくということです。

原稿への修正も、作業中に決めた方針も、うまくいかなかった実行のログも、自動的に残るようにしておくことで、取りこぼしがないようにします。

小さく始めて大きくしていくとは、こういうこと

同じ考え方を、社内の情報をAIに聞く仕組みにも使っています。

Deflagでは、案件の資料や議事録、チャット履歴、商談の記録を毎晩AIに記録させ、決まった形で蓄積し、AIが情報を探すための索引の仕組みを構築しています。

関連記事：【実験レポート】Googleドライブでメダリオンアーキテクチャを適用した簡易版データレイクハウスを構築する

そういった環境を構築しておくことで、メンバーが使っているAIから「この会社への最新の提案は？」「契約の更新が近いのは？」などと聞くと、情報元となる資料へのリンク付きで質問に回答するようになっています。

この索引の仕組みでは、AIが回答を終えると、その都度やり取りを記録します。
誰が・どんな場面で・何を聞いたか・それに答えられたかどうか。
メンバーの質問に答えられなかった場合は、その質問に応えるためにはどんな資料が必要だったかも記録してもらいます。

そうすることで、AIの回答の質を上げるために人間側が何をすればいいのかが分かるようになります。

例えば、「この会社との契約はいつ更新ですか」という質問が何度も来て、AIが答えられなかったとします。

AIが残した記録を見ると、原因はだいたい2つに分かれます。

1つは、期日の情報がAIが拾える形になっていないケースです。
契約書そのものは保存されていても、AIから見ると日付は本文の中に埋もれているだけで、どれが更新日なのかを見分けられません。

もう1つは、情報はあるのに、探すための目印が無いケースです。
社内の資料には「提案書」「議事録」のような分類ラベルを付けていますが、質問に合うラベルが無いと、AIは該当する資料までたどり着けません。

前者なら、契約書から日付だけを抜き出して一覧にします。
後者なら、ラベルを新しく足すか、既存のラベルが拾う言葉を増やします。

記録を確認することで、何を整えるべきなのかを判断できるようになり、AIが答えられる範囲をどんどん広く・詳細にしていくことができます。

メンバーが実際に聞いて答えられなかった質問を起点に改善するため、「AIの回答をよくしたい」という漠然とした改善にならず、使う人の役に立つ広げ方ができるようになるのです。

後に活用できる記録を残すためには、AIに任せっきりにしない

しかし、ただAIで記録を残せばいい。というわけではありません。

実際、先ほどお話した索引の仕組みでは、数ヶ月にわたって改善につながらない記録の集計を続けていました。

具体的にどのような集計を行っていたかというと、
まず、社内の資料にはAIが探しやすいように「提案書」「議事録」「見積」といった分類ラベルを付けています。

そして、質問に答えられなかった時の記録には、観点ラベルの中でも「どんなラベルがあれば必要な資料を見つけられたか」を書かせていました。

詳細：【実験レポート】Googleドライブでメダリオンアーキテクチャを適用した簡易版データレイクハウスを構築する

そして、同じラベルが3回溜まったら、整備するデータの候補として人間に起案し、人間が承認したものを新たな分類ラベルとして加える設計でした。

ところが、数ヶ月分を集計しても、集計されたラベルのほとんどが1回きり。
基準である3回に達しているラベルはほとんどありませんでした。

この仕組みの中で何が起きていたのか。
起案前の集計結果を見ると、同じ内容の質問（同じ意図の質問）が、違うテキスト名でラベル化され、集計されていたのです。

例えば、単数形と複数形。
日本語と英語。
「ヒアリング資料」と「インタビュー調査」。
同じ情報を求めているのに、別々の名前で記録されていました。

AIは毎回、その作業で読み込んだ情報をもとに名前を付けていたので、これまで溜めていたラベルと同じ名前を使うとは限らなかったのです。

そこで、AIが記録を書く時のルールを追加しました。
新しい名前を付ける前に既存の名前を読み、同じ意味のものがあれば、その名前を使う。
当てはまるものがない時だけ、新しく作る。
というようなルールです。

その結果、次の集計では「ヒアリング資料」と「インタビュー調査」が1つにまとまり、基準の3回を超えました。
他にも基準を満たしたラベルが、新しく分類に加わるようになりました。

新しい分類ラベルが追加されて初めて、メンバーの知りたかった内容のためにAIが情報を見つけ、回答できるようになります。
ただ記録をするだけでは、活かされないのです。

手順書×専任AIで、アウトプットの質を標準化

ここまでは、AIに渡す情報を整える話でした。
この章は、渡した情報を元にAIがアウトプットを作るまでの話です。

月次の損益の画面を最新にする、契約書をひな形から作る、作業の終わりに次にやることを書き残す。
同じステップ・同じ手順を繰り返すような業務、皆さんもあると思います。

私は、こういった繰り返す作業は手順書にして、AIがいつ実行しても同じ作業順で進められるようにしています。

例えば、私が「今日はここまで」と言うと、AIは手順書に従って変更を保存し、次回やることを書き出して終了します。
別のPCからでも続きを始められるので、その都度、どこまで進めたかを説明し直さずに済みます。

手順書だけでなく、専任AIのようなものも作成しています。
契約書を確認するためのAIや、提案書の説得力を見直すためのAIです。

普段使っているAIが、必要に応じてそれらを呼び出します。
そして、通知や認証、データベースへの接続といった処理は、共通の手順書を使うようにしています。

こうして手順や役割を書き出しておくと、都度作業を依頼するときに細かく説明する必要がなくなりますし、説明をしなくてもある程度標準化されたアウトプットを出してくれるようになります。

メンバー間で手順書や専任を共有することもできます。

とはいえ、何でもかんでも手順書や専任にしておく必要はありません。
増やしすぎると使わないものが増えたり、同じような手順書が複数できたりと、むしろアウトプットまで時間がかかってしまうような状況になります。

実際私もたくさん作ってしまい面倒くさい状況になったことがあるので、今では定期的に使わないものはAIに削除してもらっています。

別AIによるレビューも、次の仕事に引き継ぐ

AIに渡す情報を記録を元に整える。
依頼する作業を手順書として記録しておく。
最後は、アウトプットに対する人間の判断を記録しておく、です。

私のAIは、コードや文章を作成した際、別会社のAIモデルによるレビューが自動で入るようにしています。（例えば、ClaudeとCodexのように）

レビュー結果に、このままだと不具合が発生する・壊れるのような指摘があれば、保存を止めるようにしています。

最初にアウトプットを作成したAIは、自身でレビューをしたとしても前提がそのままでチェックを行い、不具合を見落とすことがよくあります。

複数回実行すると失敗する処理や、条件によって同じ行を二重に数える集計、通知の文面で項目名を取り違えている箇所などなどです。

なので、別会社のAIにレビューを入れてもらい、どんなことでも指摘してもらうようにしています。
こちらが良い設計だと思っていても、レビューをしてもらうと、前提が成り立たなくなる条件を並べてきます。

中には、いや、なんでやねん！と思うような内容もありますが、感覚では50%くらいは正しい指摘です。

採用しないものについても、なぜ対応しないのかを考え直すきっかけになっています。

そして、採用する指摘も採用しない指摘もどちらも記録に残します。
採用しない指摘は、なぜ採用しないのかも合わせてです。

そうすることで、アウトプットを出すときはこれまで指摘された内容を、
レビューするときは、過去取り下げられた指摘と理由を確認するようになるので、同じ説明を繰り返す必要が無くなりますし、私の判断も取り入れられていきます。

細かい修正や、どこまで直して打ち切るかの判断は、今も人間がしています。
それでも、別のモデルによるレビューを通すようにしたことで、凡ミスやバグはだいぶ減りました。

まずは、AIが答えられなかった質問を読む

原稿を直した理由、質問に答えるために足りなかった資料、手順と専任、レビューでの判断。

こうした情報を残し、AIが次の業務で使えるように整えてきました。
必要な資料を見つけやすくし、過去の修正や判断を引き継ぐことで、同じ説明や手直しを繰り返す手間が減っています。

資料を増やすだけでは、名前がばらばらで集計できないこともあります。
手順を増やせば、使われないものも出てきます。

だから、記録を読み返しながら、足りないものを足し、重複したものや役に立たないものは整理していきます。

AIが業務で使えるようになるために私が時間を使っているのは、環境を整える作業です。

自分の会社で試すなら、まずはAIが答えられなかった質問を10件だけ記録しておいてください。

同じような質問が続いていれば、必要な資料がないのか、あっても見つけられないのかを確かめる。
そこから、一覧を作る、分類の名前をそろえる、といった具体的な作業を決められます。
まだ記録がなければ、質問と回答、答えられなかった理由を残すところからです。

一度お話してみませんか？

deflagでは、経営判断に必要な情報を整理し、AIが使える形にするところを設計から実装までお手伝いしています。
私もここに書いた仕組みを自社で運用しながら、顧客企業にも同じ設計を導入しています。

「AIは入れたけれど、次に何をすればいいか分からない」「記録はたまっているのに、次の打ち手が出てこない」

そんな時は、今ある記録をもとに、どこから手を付けるかを一緒に考えます。

30分の相談では、記録の所在と着手する候補を整理し、その場で決められないことは、判断に必要な情報を明らかにしてお渡しします。

今使っている記録の書式や、質問のログに何を書かせているかも、そのままお見せできます。

この記事に書いた失敗も含めてお話しします。
うまくいった話より、つまずいたところのほうが参考になることも多いので。

話を聞いてみたい方は、deflag公式サイトのお問い合わせフォームか、下記のX・LinkedInからご連絡ください。

Deflagをもっと知りたい方へ

🌐 コーポレートサイト → https://deflag.net
𝕏 X（Twitter） → https://x.com/nakamae__deflag
📝 note → https://note.com/nakamae_deflag
💼 LinkedIn → https://www.linkedin.com/in/shuta-nakamae-18392828a