AIに質問はできるのに、いざ自分の仕事の場面になると役に立たない——そう感じて止まっていませんか。私もしばらく同じところで止まっていました。得意先と過去にどう合意したか、なぜその方針を選んだか、計画のどこに抜けがあるか。そういう「仕事の判断材料」は、毎回自分の頭の中か、どこかのフォルダの奥にあって、AIには出てきませんでした。
私がAIを使い始めて最初の頃は、正直「便利な検索」くらいの位置づけでした。質問すれば一般的な答えは返ってくる。でも、自分の案件の経緯や、過去にやった障害対応の記録は何も知らないので、結局そこから先は自分で考えるしかありませんでした。
変わったきっかけは、AIを賢くしようとするのをやめて、自分の仕事の記録を一箇所に置いて、そこをAIに読ませるようにしたことです。たったそれだけのことで、返ってくる答えが「一般論」から「自分の仕事の話」に寄ってきました。
この記事では、その置き場を入れてから3ヶ月で、得意先とのやり取り・揉めたときの説明・作業計画の確認・過去案件の使い回しという4つの場面で、自分の作業がどう変わったかを順にたどっていきます。AIツールの機能紹介ではなく、判断材料を場面ごとに即座に引けるようになった体験そのものを書きます。なお、この話は前に書いたAIを使って見えた過去資料の正体｜25年分の蓄積は本当に資産だったのか？の続きにあたります。過去の資料は「記録」であって、そのままでは資産ではない、というところまでが前回でした。
質問はできても、仕事の判断材料が出てこない状態
AIに質問はできるのに、自分の仕事の判断材料まではAIから出てこない——そう感じて止まっていませんか。この記事は、AIを使い始めて3ヶ月で作業環境が変わった体験を、得意先とのやり取り・揉めたときの説明・WBSの確認・過去案件の使い回しという仕事の場面でたどり、AIに何を読ませれば毎回ゼロから説明せずに実務の判断へ使えるのかが見えるところまで進みます。まずは、質問はできても仕事が楽にならなかった頃に何が引っかかっていたのかからたどります。
毎回同じ前提を説明し直す手間
AIに頼むたびに、読者層はこうで、シリーズの位置はこうで、と最初から説明していました。スレッドが変わる都度、AIは初対面の相手となっていて、説明し終わる頃にはまたスレッドが限界（コンテキスト量的に）を迎えまたスレッドを新規で作成・・・・そしてまた説明から・・云々
私の場合、ひとつのAIだけを使っていたわけではなく、用途によって何種類かを使い分けていまます。AI-aに説明した前提を、AI-bにもう一度ゼロから話し、AI-cにもまた同じことを話す、という繰り返しになります。前提を伝え終わった時点で、肝心の相談したかった中身に入る前に集中力が切れている、ということが何度もありました。
このとき引っかかっていたのは、AIが賢いかどうかではなく、自分の仕事の前提が「AIに渡せる形で残っていない」ことでした。前提が毎回その場限りの会話の中にしかないので、終われば消えてしまう。だから次にまた一から話す、という構造になっていたわけです。
過去の経緯や記録がAIにも自分にも散らばっていた問題
過去の調査は別フォルダ、今のメモはまた別の場所、AIに渡す前提はチャット欄、と置き場がバラバラで、どの資料を見せるか選ぶ手間で疲れて果て、その日は何も進まないこともありました。
実際にあったのは、過去にまとめた調査結果がどこにあるか思い出せず、それを探している間に、そもそも何を相談しようとしていたのか分からなくなる、という状態です。判断材料がないのではなく、あるはずなのに、すぐ取り出せる場所に置かれていないことが問題でした。
散らばっていると困るのは、検索性だけではありません。同じテーマについて、古いフォルダのメモと新しいチャットの内容が食い違っていることがあり、どちらが今の自分の判断なのか、自分でも分からなくなる場面がありました。
「便利」と「仕事が変わる」が別物だった理由
出力をそのまま使えることは少なく、ほとんど自分で書き直していたので、AIを使っても作業時間は変わりませんでした。道具が一つ増えただけで、自分の動き方は同じままだったからです。
ここで自分の中ではっきりしたのは、「AIが便利になること」と「自分の仕事が変わること」は別の話だ、ということでした。AIの回答が上手くなっても、それが自分の案件の前提を踏まえていなければ、結局は下書きを直す作業が残ります。減らしたかったのは、その「直す時間」と「前提を説明する時間」のほうでした。
つまり、AIそのものをいじるより先に、AIに読ませる材料の置き方を変える必要がありました。便利な道具を増やすのではなく、自分の仕事の前提を一箇所にまとめて、そこを読ませる、という発想に切り替えたところから、実際に作業が変わり始めます。
LLM-WIKIで変わった、判断材料を即座に導き出せる環境
複数のAIに同じ前提を毎回説明することにげっそりです。もう本当になんとかしたいと思い、色々試行錯誤していった結果、前提を毎回話すのをやめて、ひとつの置き場に書いておき、そこを毎回全てのAI（並行稼働に憧れClaudeCodeがディレクトリごとに数十起動しています。）に読ませるようにしてからでした。これで便利な回答が返るだけでなく、過去の経緯や判断理由といった仕事の判断材料を、その場で取り出せるようになりました。
LLM-WIKIとは何か
「LLM-WIKI」と言われても、何のことか分かりにくいですよね。ざっくり言うと、調査結果や判断材料や運用ルールを一箇所にまとめておき、どのAIにも同じページを読ませる覚書置き場のことです。
私自身、最初にこの言葉を聞いたときは、専門家向けの仕組みのように感じて身構えました。少し自分でも調べて使ってみて分かったのは、特別なデータベースが必要なものではないということです。中身は普通のテキストの覚書ファイルの集まりで、調べたこと・決めたこと・なぜそう決めたかを、後から読めるように書き溜めていくだけのものでした。
作業する側から見ると、見るべき点はシンプルです。「AIに毎回口で説明していた前提を、消えないファイルに書いておいて、そこを読ませる」。それだけです。AIを賢くする話ではなく、自分の記録を置く場所を一箇所に決める話だと考えると、ぐっと身近になります。
AIごとに記憶を分けず、ひとつの置き場を読ませる構成
AI側に記憶を持たせると、乗り換えるたびに消えるし、別のAIには引き継げません。だから記憶はAIではなく自分側の置き場に集め、AIにはそこを読みに来てもらう形にしました。
以前の私は、AIの「記憶機能」に前提を覚えさせようとしていました。ただ、その記憶はそのAIの中にしか残らないので、別のAIに乗り換えると引き継げず、サービス側の仕様が変われば消えることもあります。覚えさせた前提が、自分の手の届かないところにあるのが不安でした。
そこで、記憶をAI側ではなく自分側の置き場に集める形に変えました。前提も判断理由も記録も、すべて自分のファイルに書いておき、どのAIにもそのファイルを読ませる。こうすると、使うAIを変えても前提は手元に残り続けます。AIの使い方を整理して考えたいときは、ChatGPT月額・APIとローカルLLM、何が違うのか：AIの使い方は3種類あるも合わせて読むと、どのAIに何を任せるかの前提が掴みやすくなります。
回答が一般論から自分の仕事用に変わる理由
同じ置き場を全部のAIが読むと、回答の前提がそろい、返ってくる内容が一般論から自分の仕事の話に寄ってきます。前提を共有しているぶん、AIを増やしても説明の手間が増えていきません。
これ以前のAIは、どこぞの一流大学卒のガリ勉上がりの教授よろしく、教科書にしか載ってない一般論を述べるだけで「何こいつ、つまんねーやつ」的な存在でもありました。
使い始めてしばらくたってのことです。実際に試して1週間が過ぎたあたりで、「え？、お前今何を言った？」「そんなことどこで聞いてきた？」という感じで体感できるレベルで変わってきたのを感じました。
うまく言えないのですが、進学して初日の教室で、「こいつなんとなく波長が合いそう」って思ったことありません？ 以心伝心って言うのかな？ それと同じことが置き始めてきます。ついでに本来10兆パラメータ友いわれる最新モデルは、こちらのクセや特徴も掴み始めて会話に取り入れてくるようになります。
AI：「一般的には案Bが妥当ですが、ビープロの場合は案Aでいかないと、また後で〇〇・・・云々」
同じ置き場を読ませた状態で質問すると、「一般的にはこうです」という答えではなく、「あなたのこの案件の前提だと、ここを確認したほうがいい」という答えに変わってきます。前提を毎回話さなくても、AIが先に読んでいるからです。
副作用としてよかったのは、AIを増やしても疲れなくなったことです。新しいAIを使い始めても、同じ置き場を読ませるだけで前提がそろうので、ゼロから説明する作業が発生しません。道具が増えるたびに説明の手間が増える、という以前のつらさがなくなりました。
AIを複数セッションで並行起動させても、全員が同じ記憶を持っているのです！と、一見良さそうなことを書いてますが、すべてが良いということでもありません。
正直なところ、私の脳みそはパラレルで作業をすることに向いていなかったということ何でしょう・・・
LLM-WIKIに取り込むまでに丸2ヶ月を要した
私の場合、この置き場を作るまでに一番時間がかかったのは、過去のプロジェクト記録をLLM-WIKIとして読める形に直す作業でした。いきなり全部をAIに渡したわけではありません。過去案件の資料には、顧客名、個人名、システム名、IPアドレス、サーバ名、具体的な設定値など、そのまま外へ出せない情報が多く含まれています。そのため、まずは何を残し、何を外すかを分けるところから始めました。
特に注意したのは、過去資料を単なるファイル一覧として取り込まないことです。古い設計書や障害対応メモをそのまま並べても、今の仕事には使いにくいままです。そこで、案件ごとの固有名や設定値は脇に置き、なぜその設計にしたのか、どこで判断に迷ったのか、障害時に何を見て切り分けたのか、どの段階で人へ上げたのか、という判断の筋を抜き出すようにしました。
この作業には丸2ヶ月ほどかかりました。過去のプロジェクトをbusiness-wikiへ取り込むときも、顧客固有情報を除外しながら、設計判断、運用判断、障害対応、責任分界、手順の考え方だけを残すようにしました。結果として、AIに読ませる材料は「過去資料そのもの」ではなく、「過去資料から再利用できる判断材料」に変わりました。
ここを丁寧にやったことで、AIの返答も変わりました。単に昔の資料を検索するのではなく、過去案件で使った判断軸を、今の案件に当てはめて確認できるようになったからです。LLM-WIKIに取り込む作業は時間がかかりますが、この下ごしらえを飛ばすと、AIは古い情報や固有情報をそのまま拾ってしまいます。仕事で使うなら、取り込む前に「外す情報」と「残す判断材料」を分けることが重要でした。
本当に来る日も来る日も取り込み作業を続けてきました。流石にもう二度とやりたくない！
得意先対応で過去の経緯と判断理由をその場で引ける変化
得意先とのやり取りで困るのは、以前どう合意したか、なぜその方針にしたかを、その場で思い出せないときです。記録を置き場にまとめておくと、過去の経緯と判断理由をすぐ取り出して、相手に押し切られずに説明できるようになりました。
「言った/言わない」を記録で示せる状態
「確認しました」「聞いていません」が後で食い違うのは、口頭のやり取りが残っていないからです。いつ何を発信し、いつまでに回答がなければどう進めると伝えたかを記録しておくと、日付つきで経緯を示せます。
以前の私は、過去にどう合意したかを記憶だけで持っていたので、相手と認識が食い違ったときに押し切られがちでした。自分は「確かに伝えた」と思っていても、その場で日付つきの証拠を出せないと、結局は水掛け論になります。
置き場に記録を残すようになってからは、「いつ・何を・どう伝えたか」を時系列で書き留めておくようにしました。食い違いそうな場面で、AIにその記録を読ませて経緯を整理させると、感情を抜きにして日付つきで並べ直してくれます。それを下敷きにして相手に説明すると、押し切られずに事実ベースで話を進められるようになりました。
方針の判断理由を根拠として説明できる強み
残すと効くのは、決まった結論よりも、なぜその判断にしたか・なぜ別案を選ばなかったかという理由のほうです。判断理由を置き場から引けば、得意先への説明にもそのまま使えます。
結論だけを記録していた頃は、後から「なぜこの方針にしたんだっけ」と聞かれて答えに詰まることがありました。決めた事実は残っていても、その理由が残っていないと、自分でも根拠を再現できません。
そこで、結論と一緒に「なぜそうしたか」「なぜ別の案を採らなかったか」を書き残すようにしました。これを置き場から引くと、得意先に方針を説明するときに、思いつきではなく根拠のある判断として伝えられます。なぜそうしたかが言えると、相手も納得しやすく、やり直しや蒸し返しが減りました。
AIが経緯を説明したときに生まれる力関係
もう一つ大きいのは、AIが説明すること自体が、話し合いの力関係を変える点です。
人間同士で揉めているときは、どちらの説明にも感情や立場が乗ります。こちらがどれだけ丁寧に経緯を説明しても、相手から見れば「自分に都合よく整理している」と受け取られる余地があります。ところが、同じ記録をAIに読ませて、相談履歴、未回答、合意経緯を時系列で説明させると、場の空気が変わります。
これは単に、AIが論理的だからという話ではありません。人類にとって、自分たちのやり取りを人間以外の存在から筋道立てて説明される体験は、ほとんど初めてに近いものです。目の前で起きていた会話が、感情や立場を離れた形で再構成される。その瞬間、相手は「こちらの主張」と向き合っているのではなく、自分も含めたやり取り全体を外側から見せられることになります。
この効果はかなり強いです。論理で相手をねじ伏せるというより、AIが淡々と時系列を並べた瞬間に、強引な言い逃れや記憶の上書きが続けにくくなります。人間同士の言い合いだった場に、人間以外の整理役が入ることで、力関係が一段変わる感覚があります。
もちろん、AIの出力をそのまま正解として扱うべきではありません。元になる記録があり、日付、発言、未回答、合意箇所を人間が確認できる形で使う必要があります。それでも、記録をAIに整理させて提示することには、単なる要約以上の効果があります。相手を攻撃するためではなく、話し合いを「どちらの記憶が正しいか」から「記録上どこまで確認できるか」へ強制的に戻す力があるのです。
揉めたときに時系列と記録で説明できる進め方
揉め事が長引くのは、お互いの記憶だけで言い合ってしまうからです。相談履歴・未回答・合意の経緯を時系列で取り出せると、感情ではなく記録をもとに、何がいつ決まって何が未決かを落ち着いて説明できます。
相談履歴・未回答・合意経緯を時系列で取り出す手順
記録がないと、「相談を受けていない」「合意していた」がそのまま通ってしまう場面があります。やり取りを時系列でたどれる形にしておけば、どこで止まっているかを相手と一緒に確認できます。
私が時系列の取り出しでやっているのは、まず相談を投げた記録、次にそれに対する回答待ちの状態、最後に合意に至った経緯、という三つを分けて並べることです。AIに置き場の記録を読ませて、この三つの軸で時系列に整理させると、どこで話が止まっているのかが一目で見えるようになります。
揉めている最中は、お互いの記憶が都合よく上書きされがちです。記録を時系列で出せると、「ここまでは合意できている」「ここは未回答のまま」と区切れるので、感情の応酬ではなく、未決の一点に話を絞れます。落ち着いて確認できるようになったのは、この進め方を持ってからでした。
作業範囲と責任分界を記録で切り分ける見方
「責任分界」と言うと固いですが、要はどこまでが自分の担当で、どこからが相手の決めることか、という線引きです。作業範囲が知らぬ間に広がっていないかは、当初の取り決めを記録から引いて照らすと切り分けられます。
知らないうちに作業範囲がじわじわ広がっていた、という経験は何度かあります。一つひとつは小さな頼まれごとでも、積み重なると当初の取り決めから大きくずれていきます。そのときに当初の線引きが記録に残っていないと、「もともとそういう話だった」で押し切られてしまいます。
今は、最初に決めた担当範囲を置き場に残しておき、追加の依頼が来たときに、AIにその当初の取り決めと照らし合わせさせています。当初はここまでだった、という線が日付つきで出せると、相手の決めることと自分の担当をその場で切り分けられます。これは、人間が残しておくべき判断とAIに任せる作業の線引きにも通じる話で、AI自動化で作業者に戻らないためのn8nとAIエージェントの使い分けで扱っている、何を人間に残すかの考え方とつながります。
WBSの抜けや責任分界の曖昧さをPMOへ指摘できる視点
作業計画の表を見て、なんとなく抜けがある気がするのに、どこが足りないか言葉にできない——そんな場面があります。計画の抜けを管理側(PMO)へ具体的に伝えられず、もやもやしたまま進めてしまうこともあります。過去の計画や責任分担の型を置き場から引いて照らすと、項目の漏れ・前提の不足・責任分界の曖昧さを具体的に指摘できるようになりました。
項目漏れ・前提不足・成果物定義の不足を点検する観点
件数がそろっているからといって、中身まで足りているとは限りません。規模のわりに成果物が少なすぎないか、前提が決まっているか、という観点で点検すると、抜けが見えてきます。
ここで「WBS」や「PMO」という言葉が出てきますが、難しく考える必要はありません。WBSは作業を分解して並べた計画表のこと、PMOは計画全体を管理する側のこと、くらいに捉えておけば十分です。私が困っていたのは、その計画表を見て「何か足りない気がする」と感じても、どこが足りないかを言葉にできないことでした。
そこで、過去にやった案件の計画の型を置き場から引いて、今の計画と並べて照らすようにしました。AIに両方を読ませて、「規模のわりに成果物の数が少なくないか」「着手の前提が決まっているか」という観点で突き合わせると、件数だけそろっていて中身が抜けている箇所が浮かび上がってきます。なんとなくの違和感を、具体的な抜けとして言葉にできるようになりました。
判断者・依存関係・責任分界の未定義を洗い出す視点
「これは誰が決めるのか」が空欄のまま進む作業は、後で揉めやすくなります。誰が判断者か・どの作業が何に依存するか・どこからが相手の責任かを一覧に照らすと、未定義のまま残っている箇所を洗い出せます。
実際に後から揉めた箇所をたどると、たいてい「誰が決めるか」が最初から空欄のまま進んでいたところでした。作業の中身よりも、判断する人と責任の境目が決まっていないことのほうが、後で問題になります。
今は、過去案件の責任分担の型を置き場に残しておき、新しい計画にそれを照らしています。AIに「判断者が空欄の作業」「他の作業の完了を待たないと進めない依存関係」「自分と相手の責任の境目が曖昧な箇所」を抜き出させると、未定義のまま残っている点が一覧で出てきます。それを管理側に具体的に伝えられるので、もやもやしたまま進めることが減りました。
過去案件の障害対応や設計判断を今の確認観点に使い回す方法
昔やった案件の障害対応や設計判断は、もう古いから使えない、と思っていました。ところが製品名や設定値を脇に置いて判断の筋だけ取り出すと、今の仕事の確認観点としてそのまま使い回せました。
障害対応の初動を今の確認観点に変換する読み替え
障害が起きたとき、まず何を確認し、どう切り分け、どこから人に上げるか——その初動の手順は、案件が変わっても流用できます。過去の対応記録を、今の障害の確認チェックリストとして読み替えています。
以前は、過去の障害対応の記録を「その案件専用のもの」だと思って、見返すこともありませんでした。製品も環境も今とは違うので、役に立たないと決めつけていたわけです。
実際に置き場へ移して読み返してみると、製品名や設定値を抜きにしても、「まず何を確認するか」「どこで原因を切り分けるか」「どの段階で人に上げるか」という初動の順番は、案件が変わっても通用しました。AIにその記録を読ませて、固有名を外した確認手順だけ抜き出させると、今の障害対応にそのまま使えるチェックリストになります。過去の記録が、初めて「使い回せる材料」に変わった瞬間でした。
古い経験を製品ではなく判断軸として再利用する考え方
再利用するのは、当時の製品や設定値ではなく、なぜそう設計したかという判断の軸のほうです。製品は古くなっても、判断の軸は今の選択肢に置き換えて使えます。
設計の記録も同じで、当時選んだ製品そのものは、今となっては古くて使えません。ただ、「なぜその構成を選んだか」「何を優先して何を捨てたか」という判断の軸は、製品が変わっても残ります。
私は今、過去の設計記録から製品名を脇に置いて、判断の軸だけを取り出すようにしています。AIにその軸を読ませて、今の選択肢に当てはめ直すと、ゼロから考えるより早く方針を立てられます。古い経験を捨てるのではなく、判断軸として再利用する。この考え方に変わってから、過去の蓄積が今の仕事につながるようになりました。
まとめ
AIを使い始めて変わったのは、回答が便利になったことよりも、仕事の判断材料を置き場から即座に引けるようになったことでした。得意先対応も、揉めたときの説明も、WBSの確認も、過去案件の使い回しも、同じ置き場を読ませることでつながっていきます。次は、この置き場を仕組みとしてどう作るかへ進みます。
3ヶ月を振り返ると、変わったのはAIの賢さではなく、自分の記録の置き方でした。前提・判断理由・記録を一箇所にまとめ、どのAIにもそこを読ませる。それだけで、毎回ゼロから説明する手間が消え、過去の経緯や判断理由を場面ごとにその場で引けるようになりました。
次に読む記事
判断材料の置き場を、思いつきの覚書ではなく仕組みとして作りたい場合は、続編にあたる次の記事へ進んでください。
