AIツールは、もう一部の詳しい人だけが触る特別な道具ではなくなりました。
Claude Code、Codex、Cursor など、AIを開発作業に組み込むためのツールが広がっています。
さらに、MCP、Skills、Rules、Subagents など、AIに渡す情報や実行手順を拡張・整理する仕組みも増えています。
便利なんだけど、そのぶん「うまく使える人」と「まだ使い方を探っている人」の差も広がりやすくなっています。しかも、社員ごとに担当している案件、技術スタック、業務内容は違います。全員に同じプロンプトを配れば解決、という話ではありません。AIに任せる範囲、渡す情報量、検証の仕方、ツールの選び方は、現場ごとに判断が必要です。

だから、知見を属人化させたくないです。AI活用が得意な人のやり方をこっそり個人技にしておくのではなく、小さな工夫、迷った判断、採用しなかったAI回答、危なそうだから止めた場面を、チームで見える形にする。そうすると、他の社員が「それ、自分の仕事でも使えそう」と真似できます。

このブログで提案するのは、社員のAI利用ログを監査する運用ではありません。隔週でAI活用ケースを1件持ち寄り、どこで判断し、どこを検証し、次回どう良くするかを共有する運用です。目的は個人を点数化することではなく、社内に「真似できる使い方」を増やすこと。派手ではないけど、こういう仕組みの方が長く効きます。たぶんね。

提案するアプローチ

やることはシンプルです。以下の5ステップを隔週で回します。

1. 隔週で、AIを使った作業ケースを1件回答してもらう
2. 他の社員の回答を読む
3. 参考になる工夫に、ケース単位でバッジを付ける
4. コメントで質問・真似・注意点を残す
5. 次回のAI活用を1つだけ良くする

ここで大事なのは、提出してもらうケースを「成功事例」に限定しないことです。

うまくいった話だけだと、活用度が高い人しか書きにくくなります。AIを使い始めたばかりの人や、エンジニア初心者の人ほど、「ちゃんとした事例を書かなきゃ」と思って止まりがちです。しんどいですね。

だから、対象にしていいケースは広めにします。

• AIに任せるか迷った作業
• AIの案をそのまま採用しなかった作業
• 小さな工夫で少し楽になった作業
• うまくいかなかったけど、次回変える点が見えた作業
• 危なそうだったので、人間側で止めた作業

大きな成果でなくていいです。むしろ、小さな判断が共有される方が、他の人は真似しやすいです。

なぜログ監査ではなくケース共有なのか

AI活用の改善を考えると、AIとの会話ログやプロンプト履歴を集めて見ればいいのでは、という案も出ます。気持ちは分かります。全部見れば何か分かりそうに見えるので。

ただ、実際に運用するとなると懸念が多いです。

確認コストが大きすぎる。 AIとの会話ログは長くなりがちで、全部読むだけでかなり重いです。しかも、長いログを読んでも「この人が何を判断したのか」が必ず分かるとは限りません。

機密情報の問題がある。 ログには顧客情報、仕様、社内事情、認証やDBまわりの情報が混ざる可能性があります。監査のために集めるほど、管理しなければいけない情報も増えます。

心理的安全性が下がる。 自分のAI利用ログを見られる運用は、どうしても監視されている感覚が出やすいです。そうなると、社員は失敗や迷いを書きにくくなります。改善したいのに、改善材料が出てこなくなる。これはかなりもったいないです。

指標ハックが起きる。 AI利用回数、プロンプト数、MCP使用回数、生成コード量のような数字を主指標にすると、その数字を増やす行動が始まります。でも、AIをたくさん使うことと、良い判断ができることは別です。

プロンプト採点は長期的につらい。 AIモデルはどんどん変わります。昔は細かく手順を書いた方がよかった場面でも、今はゴール、制約、成功条件、検証観点を明確にして、解き方はAIに任せた方がうまくいくことがあります。

つまり、見るべきなのは「プロンプトがきれいか」ではありません。

見るべきなのは、次のような判断です。

• AIに任せる範囲をどう決めたか
• どんな情報を渡し、何を渡さなかったか
• AIの回答をどう検証したか
• 採用しなかった案があるなら、なぜ採用しなかったか
• リスクがある作業で、どこで人間判断に戻したか
• 次回、AIへの頼み方をどう変えるか

ログの海を掘るより、本人が選んだ1ケースを一緒に見る方が、ずっと現実的です。

1ケースだけで、本当に底上げになるのか

ここで、もうひとつ自然な懸念があります。

「隔週で1ケースだけ丁寧に共有しても、それ以外の作業では結局なんとなくAIを使うだけになるのでは？」という話です。うん、分かります。かなり現実的な心配です。

ただ、究極的には、それでもよいと思っています。この運用の目的は、社員のすべてのAI利用を管理することではありません。うまく使える工夫を、社内で見つけやすく、真似しやすく、再利用しやすい状態にすることです。

実務で本当に役に立つ使い方なら、人は自然に使います。うまく使える方法が目の前にあって、自分の仕事も楽になるなら、あえて使わない理由はあまりありません。だから、全員の全作業を追いかけるより、「これは使える」と思える具体例を増やす方が効きます。

それに、なんとなくAIを使ってうまくいっているなら、それはそのタスクに対しては十分よい使い方かもしれません。毎回、立派なプロンプトを書いたり、がちがちに手順を固めたりすることが正解とは限りません。小さい確認、小さい言い換え、軽い壁打ちで十分な場面もあります。

大事なのは、すべてのAI利用を型にはめることではなく、必要な場面でちゃんと切り替えられることです。リスクが高い作業では止まれる。影響範囲が広い作業では検証できる。曖昧な依頼ではゴール、制約、成功条件を明確にできる。そういう判断力をチームで育てたいわけです。

つまり、1ケース共有は管理のための提出物ではなく、学習素材を生み出す入口です。普段のAI利用を全部きれいに整えるためではなく、良い使い方が自然に社内へ広がるための仕組みです。

回答フォームは「的を射た質問」にする

この運用で一番大事なのは、質問設計です。

広すぎる質問は、回答を引き出せません。「AI活用で工夫したことはありますか？」と聞かれても、慣れていない人ほど「特になし」と書いてしまいます。実際には小さな工夫をしていても、それを工夫として認識できていないことが多いからです。

なので、質問は具体的にします。しかも、運用しながら磨き続けます。最初に作った質問がずっと正解、ということはありません。回答が薄くなる質問、迷わせる質問、書く負荷が高い質問は、隔週運用の中で少しずつブラッシュアップしていきます。

ここでは、6問に絞ります。

Q1. 対象ケース

この期間で、AIの使い方に何らかの工夫・判断・迷いがあったタスクを1つ書いてください。成果が大きかったタスクでなくても構いません。

書くとよいことは、どんな作業で、どこにAIを使ったのかです。作業の規模は小さくて大丈夫です。

回答例:

一覧画面のフィルタリング処理で、条件を組み合わせると件数が正しく絞り込まれないケースがあり、AIと一緒に原因を調査して修正した。

初心者の場合は、もっと短くてもいいです。

エラー内容をAIに説明してもらい、原因になりそうなファイルを一緒に探した。

これで十分です。どこからAIを使ったかが見えれば、次の会話につながります。

Q2. 自分で判断した部分

今回、AIに全部任せず、自分で判断した部分はどこですか？ 採用した案、採用しなかった案、修正範囲を狭めた判断などを書きます。

ここはかなり重要です。AI活用の質は、AIに何をさせたかより、人間がどこで舵を握ったかに出ます。

回答例:

AIはフィルタリングロジックを共通ユーティリティに切り出してテストを整備する案を出したが、今回は対象の絞り込み処理だけを直す方が安全と判断した。リファクタリングは別タスクで対応する方針にした。

初心者向けの回答例:

AIの説明だけでは不安だったので、先輩に確認してから修正した。自分では、まずエラーが出ている画面だけを見ることにした。

「自分で判断した」と言われると難しく感じますが、実際は「AIに言われたけど一回止まった」「誰かに確認した」「範囲を小さくした」も立派な判断です。

Q3. 採用しなかったAI回答

AIの回答で、そのまま採用しなかった部分はありますか？ あれば、なぜ採用しませんでしたか？ なかった場合は空欄でもOKです。

この質問は任意です。毎回あるとは限りません。

ただ、採用しなかった回答には学びが多いです。AIの案を疑う、既存仕様と比べる、影響範囲を見る。こういう判断は、他の社員にとってかなり参考になります。

回答例:

AIはフィルタ条件の管理方法を全体的に見直す案を提案したが、影響範囲が広すぎるため採用しなかった。今回の不具合は特定条件の組み合わせ時のみ発生するため、その箇所だけをピンポイントで修正する判断をした。

初心者向けの回答例:

AIが出したコマンドの意味が分からなかったので、そのまま実行しなかった。あとで調べたら、不要なファイルまで変更しそうだった。

これはすごく良い回答です。分からないコマンドを実行しないのは、ちゃんとしたAI活用です。

Q4. 意図的に工夫したこと

AIの回答精度、作業効率、安全性を上げるために、意図的にやったことを選び、具体的に書きます。

選択肢はこのくらいにします。

• 任せ方を工夫した
• 情報の渡し方を工夫した
• 会話・セッション管理を工夫した
• ツール・機能の使い分けを工夫した
• AI回答の検証・取捨選択を工夫した
• 再利用・共有できる形にした
• 上記にあてはまらない独自の工夫をした
• 特になし

回答例:

会話・セッション管理、ツール・機能の使い分け、AI回答の検証・取捨選択を選択。Claude Codeのプランモードで修正案を出させたが、影響範囲が大きい案だったためそのまま進めず、ChatGPTにまっさらな状態で別案を確認した。

初心者向けの回答例:

エラー文だけでなく、直前に自分が変更したファイル名もAIに伝えた。最初より原因の候補が絞りやすくなった。

小さいですね。でも、これでいいです。こういう小さい工夫が積み上がると、チーム全体のAI活用がじわっと良くなります。

Q5. 次回変えること

次に同じ作業をAIで行うなら、先にAIへ伝える情報を1つ増やす、または減らすとしたら何ですか？ 1点だけでOKです。

改善は欲張らない方が続きます。毎回1つでいいです。

回答例:

最初から「他画面への影響を最小化したい」「共通のユーティリティはなるべく触らない」という制約を伝える。

初心者向けの回答例:

次は、エラー文だけでなく、自分が試したことも先に書く。AIに同じ確認を何度もさせないようにする。

「次回は何を変えるか」が残っていると、次のケースレビューで改善を確認できます。

Q6. 他の人が真似できそうなポイント

大きなノウハウでなくて構いません。「この聞き方は使えそう」「この切り分け方は便利だった」くらいでOKです。

この質問も任意です。ただ、チームの底上げにはかなり効きます。

回答例:

AIにいきなり修正させる前に、複数案の影響範囲を比較させてから、最小影響の案を選ぶ進め方。1つのAIセッションで修正案が大きくなりすぎた場合は、別AIや別セッションで別案を確認する進め方。

初心者向けの回答例:

エラーを貼る前に「初心者にも分かる言葉で、原因候補を3つに絞って」と伝えると理解しやすかった。

こういう回答は、他の初心者にもすぐ使えます。すごく実用的です。

コメントは評価ではなく、学習の反応

コメント欄は、採点する場所ではありません。

「それは違う」「もっとこうすべき」と詰める場所にすると、すぐ誰も書かなくなります。やだね、そういうの。

コメントの役割は、提出されたケースを次の学習につなげることです。投稿者だけでなく、読む人、質問する人、真似する人も運用の参加者になります。

使いやすいコメント種別は、次の5つです。

• 参考になった
• 真似したい
• 質問したい
• 自分も試した
• 注意点あり

コメント例:

参考になった: この /btw の使い方は、自分の実装相談でも使えそうです。

真似したい: AIに修正させる前に、複数案の影響範囲を比較させる進め方を真似してみます。

質問したい: セッションを分けるタイミングは、どのくらい会話が長くなった時に判断しましたか？

自分も試した: 似たログ調査で、この整理方法を試したら、確認漏れが減りました。

注意点あり: DB変更系では、AIにSQLを書かせる前に既存マイグレーションの確認も入れた方が安全そうです。

同じような回答が増えるのでは、という懸念もあります。これは、あまり問題にしなくていいと思います。

他者の回答を読んで「この使い方いいな」と思い、自分の作業に取り入れる。それは立派なAI活用です。むしろ、どんどん真似してほしいです。

「○○さんの使い方を真似しました」

これも価値ある回答です。よくある回答が増えるのは、良い工夫が社内に広がっているサインでもあります。もちろん、完全なコピペだけで実務に接続していないなら改善が必要ですが、真似して、試して、自分の案件に合わせて少し変えるなら、それはちゃんと成長です。

バッジは能力証明ではなく、参考ポイントのラベル

バッジは、人をランク付けするためのものではありません。

「Aさんは優秀」「Bさんはまだまだ」という見方を始めると、運用が一気に息苦しくなります。ここで見るのは人ではなく、ケースです。

つまり、こう見ます。

Aさんの今回のケースには、コンテキスト管理の参考になる工夫がある。

Bさんの今回のケースには、AI回答を採用しなかった判断がある。

1ケースにつき、バッジは最大2から3個程度にします。多すぎると意味が薄くなるので、特に参考になるポイントだけ拾います。書かれていないことは減点しません。推測でも付けません。

リスクガーディアン

危ない作業でAIを止め、人間判断に戻せたケースに付けます。

対象になりやすいのは、本番影響、DB変更、認証、セキュリティ、顧客情報、仕様判断が必要な作業です。

例:

DB変更を伴う可能性があったため、AIには影響範囲と確認観点の整理だけを任せた。実際にどのカラムを変更するかは、人間側で既存仕様と本番影響を確認して判断した。

メリットは、AIに任せない判断も良い活用として見えることです。使うことだけがAI活用ではありません。止まれる人は強いです。

スキル鍛冶師

一度きりのAI活用で終わらせず、次回も使える手順、Skill、Rules、チェックリストとして残したケースに付けます。

例:

今回のログ調査は今後も似たケースがありそうだったため、最後にAIへ調査手順を整理させ、次回使えるチェックリストとして残した。

メリットは、個人の工夫がチームの資産になりやすいことです。できる人の頭の中だけにあった手順を、他の人も使える形にできます。

ツール軍師

AI開発支援ツールや拡張機能を、目的・作業内容・リスクに応じて使い分けられたケースに付けます。
例：Claude Code、Codex、Cursor、MCP、Skills、Rules、Subagents、スラッシュコマンドなど

大事なのは、使ったことではなく、選んだ理由です。

例:

新機能の実装と並行して、Supabase MCPを使いDBのテーブル設計とマイグレーションをAIに進めてもらった。実装コードとスキーマの整合性をリアルタイムで確認しながら開発できたため、後から仕様ズレに気づくような手戻りが少なかった。

メリットは、ツール名の流行に振り回されにくくなることです。使わない判断も、ちゃんと共有価値があります。

コンテキスト航海士

AIに渡す情報、渡さない情報、会話やセッションの分け方を意図的に管理できたケースに付けます。

例:

修正方針の本筋とは別に、軽く気になった点は別の会話で質問した。本筋に混ぜると、AIが修正範囲を広げすぎる可能性があったため。実装方針の会話には、対象コード、修正方針、制約だけを残した。

メリットは、AIとの会話が濁りにくくなることです。AIは文脈の影響を強く受けるので、何を入れて、何を入れないかはかなり大事です。

検証アナリスト

AIの回答を鵜呑みにせず、疑い、比較し、既存仕様やテストと照合したケースに付けます。

例:

AIが提案した修正方針は、考えられる影響範囲を幅広くカバーした丁寧な内容だったが、今回の運用では対象外にしてよいケースまで含まれていた。実際に問題が発生するケースに絞って再判断し、より影響範囲の小さい修正にした。

メリットは、AIを使うほど必要になる検証力を共有できることです。AIが賢くなるほど、もっともらしい間違いも見抜きにくくなります。だからこそ、人間側の検証プロセスを見える化します。

AI発明家

既存カテゴリに収まらないが、他の社員が真似したくなる実務上の工夫があるケースに付けます。

例:

実装方針を決める前に、AIに「この方針に反対するレビュアー」の立場で懸念点を出させた。その結果、見落としていた既存画面への影響に気づけた。

メリットは、新しい使い方を拾えることです。AIツールは変化が速いので、最初から分類しきれない工夫が出てきます。その余白をちゃんと残します。

活用度が低い人ほど、書くメリットがある

AIを使い始めたばかりの人は、「自分の回答なんて役に立たない」と思うかもしれません。

でも、むしろ書いた方がいいです。

初心者のつまずきは、他の初心者にとって一番分かりやすい教材になります。エキスパートの高度な使い方も大事ですが、最初の一歩で何に困ったか、何をAIに聞いたら理解しやすくなったか、どこで怖くて止まったかも、かなり価値があります。

例えば、こんな内容で十分です。

• エラー文を貼るだけでは分からなかったので、自分が直前に変更したファイルも伝えた
• AIが出したコマンドの意味が分からなかったので、そのまま実行しなかった
• 先輩に聞く前に、AIに質問案を整理してもらった
• AIの説明が難しかったので、「初心者向けに言い換えて」と頼んだ
• 次回は、試したことを先に書くようにする

これらは全部、AI活用の改善です。

「すごい使い方」だけを集めると、一部の人の発表会になります。でも、「小さな判断」も集めると、チーム全体の学習になります。底上げって、そういう地味なところから始まるんだと思います。

運用するときのコツ

この仕組みは、作って終わりではありません。運用しながら育てます。

まず、隔週くらいの頻度で始めるのがちょうどいいです。週1だと重くなりやすいですし、月1だと記憶が薄れます。さらにAIツールは機能追加や使い方の変化が速いので、月1では「先月の良いやり方」がもう少し古くなっている可能性もあります。隔週なら、最近の作業を思い出しやすく、AIツールの変化にも追いつきやすいです。

次に、回答フォームは固定しすぎないことです。回答が薄い質問があれば、質問文を変えます。似た回答ばかりになるなら、例を増やします。初心者が書きにくそうなら、「小さな迷いでもOK」と明記します。

バッジも、最初は6種類で十分です。増やしすぎると迷います。運用してから、本当に必要なカテゴリだけ追加すればいいです。

コメントは、最初から完璧な文化にはなりません。まずは運営側やAI活用に慣れている人が、「参考になった」「真似したい」「この観点も良さそう」と軽くコメントして、空気を作るのがよいです。

そして、ランキングは出さない方がいいです。バッジ数、コメント数、投稿数を競わせると、学習のための場が成果アピールの場に変わります。数字は運用の健康診断として見るくらいで十分です。

まとめ

社員のAI活用スキルを底上げするには、正解プロンプトを配るより、AI活用の判断を共有できる仕組みを作る方が強いです。

この運用なら、初心者も参加しやすく、上級者の工夫も共有されやすくなります。AIツールが変わっても、運用自体を少しずつ更新できます。

AI活用エキスパートチームは、最初から一部のすごい人だけで作るものではありません。

小さなケースを持ち寄って、うまい使い方を真似して、危ない使い方を避けて、次回ひとつ良くする。その積み重ねで、チーム全体がじわじわ強くなっていきます。

それくらいの温度感が、たぶん一番続きます。