AIをベテラン社員のように働かせる会社は、何を渡しているのか
月曜の朝、週次レビューの30分前。
画面の左には、まだ粗い原稿と資料メモ。右には、AIのチャット画面。
私は同じ説明を、また入力していました。
「この文章は少し硬いので、もう少し自然に」
「この企画は断定しすぎないで」
「投資の話に見えるけれど、購入推奨にはしないで」
「最初に結論を出しすぎず、読者が考えられる余白を残して」
AIは、それなりに応えてくれます。
原稿の言い回しも整う。抜けていた反論も出る。レビュー前の焦りも少し減る。
それでも、入力欄に同じ注意を書きながら、ふと引っかかりました。
人間の同僚なら、ここまで毎回ゼロから説明しないはずです。
何度か一緒に仕事をした人なら、こちらの癖を覚えている。
どの表現を嫌がるかも知っている。
どこまで踏み込むと危ないかも、だんだん分かってくる。
ベテラン社員に仕事を頼むとき、私たちは作業指示だけを渡しているわけではありません。
背景を渡している。
評価基準を渡している。
過去の失敗を渡している。
関係者の温度感を渡している。
「ここは雑に見えて、実は効く」という暗黙知も渡している。
では、AIに仕事を頼むとき、私たちは何を渡しているのでしょうか。
この問いは、単なるプロンプト術の話ではないと思います。
生成AIが社会に広がるほど、差が出るのは「AIに何を聞けるか」だけではない。
むしろ、AIが失敗から学び、過去の文脈を使い、次回もっとよく働ける環境を作れるか。
そこに、会社や個人の見えにくい差が出てくるのではないか。
この記事では、HITL、自己改善ループ、コンテキスト設計という三つの言葉を、できるだけ分かりやすく整理しながら、AIを「毎回新人の道具」ではなく、「少しずつ仕事を覚える相棒」に近づける条件を考えてみたいと思います。
HITLは必要だが、それだけでは毎回新人のまま
まず、HITLという言葉があります。
Human in the Loop の略で、AIの出力を人間が確認したり、承認したりする仕組みのことです。
ざっくり言えば、AIに任せっぱなしにせず、人間が最後に見る、という考え方です。
これはとても大事です。
AIの回答には間違いがあり得る。
根拠が薄いこともある。
もっともらしく見えるが、前提がずれていることもある。
特に法務、医療、投資、採用、行政手続きのような領域では、AIが出したからといってそのまま使ってよいわけではありません。
だから、人間が確認する。
これは必要です。
ただ、私は最近、HITLだけでは足りないのではないかと感じています。
なぜなら、HITLだけの設計では、AIが毎回「新人」のままだからです。
AIが出す。
人間が直す。
そこで終わる。
この直線だけだと、人間は毎回レビュー担当になります。
修正理由は人間の頭の中に残る。
AIは次回も、また似たところで外す。
もちろん、チャットの履歴が残ることはあります。
しかし、仕事の仕組みとして「前回の失敗が次回の標準に反映される」ように設計されていなければ、改善は偶然に近い。
これは、新人育成に似ています。
新人が文書を作る。
先輩が赤を入れる。
でも、なぜ直したのかを伝えず、チェックリストも残さず、次回も同じ形式で頼む。
これでは、新人は育ちにくい。
先輩もずっと忙しい。
AIでも同じことが起きます。
HITLは「事故を防ぐブレーキ」として重要です。
しかし、それだけでは「運転が少しずつ上手くなる仕組み」にはなりません。
自己改善ループを作る
そこで必要になるのが、自己改善ループです。
自己改善ループとは、失敗や修正理由を、次回の仕事に反映する循環のことです。
難しく言えば継続的改善ですが、もっと日常的に言うなら「前回の反省を、次回のやり方にちゃんと組み込む」ことです。
AI活用では、たとえばこういう流れになります。
依頼する。
AIが出力する。
人間が確認する。
どこを直したかを記録する。
なぜ直したかを短く言語化する。
次回のプロンプト、チェックリスト、ナレッジ、テンプレートに反映する。
ここまでやって、ようやくループになります。
ここで見たいのは、AIの失敗を叱ることではありません。
失敗を、次回の仕事環境に埋め込むことです。
たとえば、AIが毎回「断定的すぎるタイトル」を出すなら、単にその場で直すだけでは弱い。
「タイトルでは結論を言い切らない」
「本文で扱う不確実性を残す」
「読者の不安を煽らない」
この三つを、次回のタイトル生成条件に入れる。
AIが毎回、外部情報の鮮度を曖昧にするなら、
「直近情報は日付を確認する」
「公式情報、一次情報、信頼できる報道を分ける」
「未確認ならHypothesisと書く」
という確認項目を標準にする。
AIが毎回、投資の話で強すぎる表現を出すなら、
「購入、売却、保有を推奨する表現は禁止」
「企業や市場は、社会変化を読む補助線として扱う」
「上がる、勝てる、確定のような言葉は使わない」
と明文化する。
こうすると、AI活用は一回ごとの作業ではなくなります。
失敗が残る。
修正理由が残る。
次回の依頼が少し良くなる。
これは地味ですが、かなり大きい差になります。
なぜなら、AIの出力品質は、モデル性能だけで決まらないからです。
同じAIを使っていても、毎回ゼロから頼む人と、失敗をチェックリストにして蓄積する人では、半年後の仕事の質が変わる。
同じAIを導入していても、出力を直して終わる会社と、修正理由を組織知にする会社では、導入効果が変わる。
ここに、生成AIが仕事に入る局面の見えにくい競争力があると思います。
コンテキスト設計とは何か
次に、コンテキスト設計です。
コンテキストとは、文脈のことです。
コンテキスト設計とは、AIが判断に使える背景情報を、整えて渡すことです。
人間に仕事を頼むときも、文脈が足りないとズレます。
「この文書を作って」だけでは、よい文書は作りにくい。
誰に見せるのか。
何を決めたいのか。
相手は何を心配しているのか。
前回どこで揉めたのか。
今回はどこまで決めればよいのか。
触れない方がよい論点は何か。
こうした文脈があると、仕事の質は変わります。
AIも同じです。
むしろAIは、人間以上に、渡された文脈に強く左右されます。
ここで参考になるのが、Microsoft 365 Copilotの考え方です。
Microsoftは、Microsoft 365 Copilotについて、大規模言語モデルとMicrosoft Graph上の仕事データ、Microsoft 365アプリを組み合わせるものとして説明しています。Microsoft Graphには、カレンダー、メール、チャット、ドキュメント、ミーティングなどの仕事上のデータが含まれるとされています。
ここで重要なのは、特定製品の宣伝ではありません。
AIが賢く働くには、単に賢いモデルがあるだけでは足りない、という点です。
仕事の背景を持っていること。
過去の会話や文書にアクセスできること。
その人や組織の文脈に沿って動けること。
これが、AIを「検索窓」から「仕事環境」に近づけます。
最近、Work IQという言葉で、こうした仕事文脈の理解が語られることがあります。
ただし、この記事ではWork IQを特定機能名として厳密に説明するのではなく、「AIが仕事の背景を理解するレイヤー」という考え方として扱います。
AIに渡すべき文脈は、少なくとも七つあります。
目的。
何を決めたいのか。何を避けたいのか。
評価基準。
速さを優先するのか、正確さを優先するのか。読者の納得を重視するのか、網羅性を重視するのか。
過去事例。
以前うまくいったもの。失敗したもの。似ているが使ってはいけない型。
禁止事項。
法務、倫理、ブランド、個人情報、炎上リスク、投資助言に見える表現など。
関係者。
誰に向けた仕事なのか。誰が不安を持つのか。誰が最後に判断するのか。
好み。
文体、粒度、説明の深さ、図解の使い方、タイトルの温度感。
例外処理。
分からないときにどうするか。止めるのか、仮説として出すのか、人間に戻すのか。
これらを渡さずにAIへ頼むのは、ベテラン社員に「いい感じでお願い」と言うより難しい。
人間なら空気で補える部分も、AIには設計として渡す必要があるからです。
他領域から借りると、見え方が変わる
この話は、AIだけで考えると少し抽象的です。
そこで、別の領域から概念を借りてみます。
概念転用は、難しい言葉を増やすためではありません。
見えにくい構造を、別の分野の知恵で照らすために使います。
改善活動: 失敗を次の標準にする
改善活動とは、仕事の小さなムダやミスを見つけ、次のやり方に反映していく考え方です。
身近な例で言えば、毎回探しているファイルがあるなら、置き場所や名前を変える。
毎回説明している注意点があるなら、チェックリストにする。
AI活用にも、そのまま当てはまります。
毎回AIが外すポイントは、能力不足として片づけるのではなく、標準化の材料にする。
「このAIは分かっていない」と終わらせるのではなく、
「この仕事では、何を前提として渡せていなかったのか」と見る。
この視点に変えるだけで、AIとの付き合い方はかなり変わります。
SREのポストモーテム: 誰が悪いかではなく、なぜ再発するかを見る
SREという領域には、ポストモーテムという考え方があります。
ポストモーテムは、障害や事故のあとに、何が起きたのか、なぜ起きたのか、どうすれば再発しにくいのかを振り返る活動です。
GoogleのSRE本でも、ポストモーテム文化は運用改善の重要な要素として扱われています。
ここで避けたいのは、犯人探しです。
誰が悪かったかではなく、なぜそのミスが起きる構造だったのかを見る。
AI活用でも、同じです。
AIが間違えた。
人間が見抜けなかった。
そのときに「AIは信用できない」で終わると、学びが残りません。
なぜその出力を採用しそうになったのか。
どの前提が足りなかったのか。
どのチェックがなかったのか。
人間に戻す条件は明確だったのか。
ここまで見て、次の設計に戻す。
これが、生成AIを仕事に入れるときのポストモーテムです。
チェックリスト: 熟練者でも抜けるものを仕組みにする
チェックリストは、医療や航空のような高リスク領域でよく使われます。
一言でいえば、熟練者でも抜ける確認を、手順として外に出す仕組みです。
WHOも手術安全チェックリストを公開しています。
チェックリストというと、初心者向けのものに見えるかもしれません。
でも、本当は逆です。
難しい仕事ほど、頭の中だけに頼らない。
熟練者ほど、抜けやすいポイントを仕組みに逃がす。
AI活用でも、これは効きます。
たとえば、AIが作った文章を読むとき、毎回感覚で直すのではなく、三つだけ確認する。
事実と仮説が混ざっていないか。
読者を煽っていないか。
根拠が必要なところに出典があるか。
この三つだけでも、出力の安全性は変わります。
完璧なチェックリストを作る必要はありません。
むしろ長すぎるチェックリストは使われなくなります。
小さく始め、失敗したら項目を足す。
それが自己改善ループです。
徒弟制: ベテランの判断を横で見る
徒弟制という言葉があります。
昔ながらの職人の世界で、見習いがベテランのそばで仕事を見ながら学ぶ仕組みです。
現代の仕事でも、似たことはあります。
レビューの場で、ベテランがどの順番で論点を整理するか。
顧客への返信で、どこを柔らかくするか。
企画書で、何を削るか。
こうした判断は、マニュアルだけでは伝わりにくい。
横で見て、理由を聞き、少しずつ身体化していくものです。
AIにこの徒弟制をそのまま適用することはできません。
AIは人間のように経験を生きているわけではないからです。
でも、転用できる部分はあります。
ベテランの判断を、例として残す。
修正前と修正後を残す。
なぜ変えたのかを一行で残す。
これをAIに渡せる形にしておく。
AIに「空気を読め」と言うのではなく、空気の中身を少しずつ言語化して渡す。
これが、生成AIを仕事に入れるときの徒弟制に近いのではないかと思います。
投資の複利: 一回の効率化より、改善が積み上がること
投資の世界には、複利という考え方があります。
得られた利回りが次の元本に加わり、時間がたつほど差が広がる、という考え方です。
ここで個別銘柄や資産の購入を勧めたいわけではありません。
借りたいのは、複利という見方です。
AI活用でも、一回の効率化だけを見ていると、差は小さく見えます。
メールが少し早く書けた。
議事録が少し早くまとまった。
文書のたたき台が少し早く出た。
それも大事です。
でも、本当に差が開くのは、改善が次の改善を生むときです。
一回の修正がチェックリストになる。
チェックリストが次回のプロンプトになる。
プロンプトがチームの標準になる。
標準が新しい人の立ち上がりを助ける。
この積み上がりは、単発の時短より大きい。
AI活用の差は、今日の一回の出力ではなく、半年後にどれだけ仕事の標準が賢くなっているかに出るのかもしれません。
行政DXで考えると、さらに分かりやすい
この話は、企業だけでなく行政DXにもつながります。
行政DXというと、オンライン申請やチャットボットを思い浮かべる人が多いかもしれません。
もちろん、それも大事です。
でも、生成AIを前提にした行政DXで難しいのは、窓口をチャット化することだけではないと思います。
制度の背景。
申請者の状況。
例外処理。
過去の問い合わせ。
説明責任。
人間へ戻す条件。
こうした文脈を、どこまで整理できるか。
もしAIチャットボットが、制度の本文だけを読んで回答するなら、便利ではあっても危うい。
制度には例外があります。
言葉の定義があります。
自治体や部署ごとの運用差があります。
本人確認やプライバシーの問題もあります。
だから、行政DXでも重要なのは、AIに答えさせることだけではない。
どこまでをAIに任せるか。
どこから人間に戻すか。
回答の根拠をどう追えるようにするか。
誤った案内が出たとき、どう修正し、再発を防ぐか。
ここにも、HITL、自己改善ループ、コンテキスト設計が必要になります。
公共サービスは、一部の人だけが使うものではありません。
高齢者、外国人、障害のある人、忙しくて手続きに時間を割けない人、制度に詳しくない人も使います。
だからこそ、AI導入は「便利そう」で終わらせてはいけない。
誰にとって便利なのか。
誰が取り残されるのか。
間違ったときに誰が困るのか。
そこまで含めて設計する必要があります。
投資観察で見るなら、企業のAI導入は「単発効率化」か「組織学習」か
株式投資の話にも、少しだけ触れます。
ただし、これは特定の企業、業種、資産の購入や売却を勧める話ではありません。
投資判断は個別事情によって大きく変わりますし、この記事は投資助言ではありません。
私が関心を持っているのは、AI導入を社会変化としてどう見るかです。
多くの企業がAIを導入します。
議事録を作る。
問い合わせ対応をする。
社内検索をする。
文書作成を補助する。
ここまでは、比較的分かりやすい。
でも、長期的に差が出るのは、その先ではないかと思います。
AIを単発の効率化で終わらせる企業。
AIの失敗と修正を、業務標準やナレッジに戻す企業。
この二つは、同じツールを使っていても違う会社になります。
前者は、AIで少し速くなる。
後者は、AIによって組織の学習速度が上がる。
この差は、短期のニュースでは見えにくいかもしれません。
しかし、採用、教育、問い合わせ、開発、営業、管理部門のあちこちで、改善が積み上がるなら、時間とともに差は広がります。
投資観察として見るなら、私は「どのAIツールを入れたか」だけでなく、次の問いを見たい。
AIの出力を誰がレビューしているか。
レビュー結果は次回に反映されているか。
失敗したときのポストモーテムがあるか。
AIが使う文脈は整理されているか。
人間に戻す条件は明確か。
これは、派手なニュースではありません。
でも、企業がAIを本当に使いこなすかを見るうえでは、かなり重要な補助線になるはずです。
明日使える一手: 一行の学習台帳
では、個人として何から始めればよいのでしょうか。
大きなシステムを作る必要はありません。
まずは、自分のAI活用に小さな自己改善ループを入れるだけでいいと思います。
翌週に試すなら、最初は一行で十分です。
「この仕事で、AIに任せた部分と、自分が引き受けた判断は何か」
この問いを、作業後に一文だけ残す。
それが、小さな学習台帳になります。
一つ目。
AIに頼んだ仕事で、毎回直すポイントを三つだけメモする。
仕事の現場で同じ修正が続くなら、それは個人の注意力ではなく、渡している文脈の不足かもしれません。
二つ目。
その修正理由を、次回の依頼文に一行だけ足す。
三つ目。
AIが迷ったら人間に戻す条件を決めておく。
たとえば、出典が必要な事実、個人情報、投資判断、法務や医療に関わる話、他人の評価に関わる話は、AIだけで進めない。
四つ目。
うまくいった出力も、なぜよかったのかを残す。
「簡潔だった」だけではなく、
「反論を先に置いたから読みやすかった」
「結論を急がず、読者の違和感から入ったから自然だった」
「図解が判断手順を補っていたから保存価値が出た」
こうして言語化する。
五つ目。
AIに渡す文脈を、毎回ゼロから書かない。
目的、評価基準、禁止事項、好み、過去事例を、小さなメモとして持っておく。
これだけで、AIは少しだけ「自分の仕事を知っている相手」に近づきます。
結論: AIに命令する力より、AIが働ける環境を作る力
生成AIの話は、どうしてもモデル性能に目が向きます。
どのモデルが賢いか。
どのツールが速いか。
どの機能が新しいか。
もちろん、それは重要です。
でも、仕事や社会の中でAIを使うなら、もう一つ別の問いが必要です。
そのAIは、仕事の文脈を持っているか。
失敗が次回に反映されるか。
人間に戻す条件はあるか。
チェックリストは育っているか。
過去の判断は、次の人にも使える形で残っているか。
これから必要になるのは、AIに命令する力だけではない。
AIが賢く働ける環境を設計する力です。
HITLは、その入口です。
人間が最後に見ることは、これからも必要です。
ただ、それだけで終わらせると、人間はずっとレビュー係になります。
AIはずっと毎回新人のままです。
問いは、その先にあります。
人間が直した理由を残す。
失敗を次の標準にする。
AIに渡す文脈を整える。
改善が積み上がる仕事の仕組みを作る。
そうした地味な設計が、AIを単なる便利ツールから、少しずつ仕事を覚える環境へ変えていくのだと思います。
たぶん、これから仕事の現場で問われるのは、AIを使っているかどうかではありません。
AIに仕事を覚えてもらえる形で、自分たちの仕事を整理できているか。
そこに、個人の仕事力も、組織の強さも、社会のデジタル化の成熟度も表れていくのではないでしょうか。
出典・参考
Microsoft 365 CopilotがMicrosoft GraphとMicrosoft 365アプリの仕事データを組み合わせるという説明を確認しました。
SREのポストモーテム文化について、Google SREの公開情報を参考にしました。
医療安全におけるチェックリストの例として、WHOのSurgical Safety Checklist関連情報を参考にしました。
この記事は所属組織とは関係のない、個人としての考察です。
