職場でのAI導入の取り組みや、日々の情報収集を続けていると、AI利活用について、少しずつ見え方が変わってきました。
最初は、どのAIツールを使うか、どういうプロンプトを書くか、どの業務に適用するか、という話が中心になります。もちろん、それはそれで大事です。ただ、実際に使い続けていると、もう少し手前にある問題が気になってきます。
それは、AIとの距離感をどう設計するか、という話です。AIに近づきすぎれば、AIの出力に引っ張られます。逆に、AIに遠くから丸投げしすぎれば、今度は人間側の関与が薄くなります。どちらも便利ではあるのですが、業務として安定しているかというと、少し怪しいところがあります。
2026年6月時点で、AI Nativeな働き方について考えるなら、この「距離感」の話を避けて通れないのではないかと感じています。
HITLは否定しない。ただし、成立させるには工夫がいる
AIによって生成された成果物については、人間がレビューし、最終的な説明責任を負う。いわゆるHITL、Human-in-the-Loopの考え方は、AI活用において広く支持されている考え方です。
これは基本的には正しいと思います。AIはもっともらしい誤りを出すことがあります。前提を取り違えることもありますし、こちらが与えていない条件を勝手に補ってしまうこともあります。組織としてAIを使う以上、「AIがそう言ったからです」では説明になりません。最終的には人間が確認し、判断し、責任を持つ必要があります。
ただ、最近はこのHITLにも、実務上の難しさが見え始めているように感じます。たとえば、AIに詳細な調査をさせたり、大きなタスクを任せたりすると、アウトプットの量が一気に膨らみます。数ページの要約ならまだしも、数十ページ規模のレポート、複数資料の比較、コードの大きな修正、業務プロセス全体に関わる提案となると、人間がレビューすべき対象そのものが大きくなりすぎます。
差分も同じです。AIに「この資料を改善して」と依頼すると、表現だけでなく、構成、論点、前提、結論のニュアンスまで変わることがあります。すると人間は、単に誤字脱字を見るのではなく、何が変わったのか、なぜ変わったのか、その変更は妥当なのかを追いかけなければなりません。
これが結構しんどい。HITLは、人間がループの中にいることを前提にしています。しかしAIの出力が大きくなりすぎると、人間はループの中にいるつもりでも、実際には流れてくる成果物を後ろから追いかけるだけになります。
要するに、レビューできないサイズの成果物に対しては、責任も持ちにくいということです。ここを曖昧にしたまま、「最後は人間がレビューします」と言ってしまうと、実態としてはかなり危ういと思っています。HITLを否定したいわけではありません。むしろ逆で、HITLを実務として成立させるには、人間が理解し、判断し、責任を持てる単位に仕事を分け直す必要があるのだと思います。
AIエージェントで、人間の関与は薄くなりやすい
この問題は、AIエージェントによる自律的なタスク実行が進むほど、さらに大きくなりやすいと思っています。
AIエージェントは、ユーザーの指示を受けて、調査し、判断し、ツールを操作し、成果物を作る方向に進んでいます。これは便利です。人間が細かく指示しなくても、一定の目的に向かってタスクを進めてくれるからです。
一方で、自律性が高まるほど、ユーザー側の関与は薄くなりがちです。最初に依頼を出して、しばらくして結果を受け取る。すると、人間はプロセスの途中で何が起きたのかを十分に把握できないまま、最後の成果物だけをレビューすることになります。
この状態では、レビューはどうしても形式的になりやすいです。なぜなら、成果物に至るまでの探索経路、判断の分岐、捨てられた選択肢、前提の置き方が見えにくいからです。最終成果物だけを見ても、なぜその形になったのかが分からない。分からないものをレビューするのは、だいぶ難しいです。
もちろん、AIエージェントそのものが悪いわけではありません。途中で確認を挟む、実行前に承認を取る、根拠や差分を見えるようにする、後から戻れるようにしておく。そうした設計があれば、むしろ人間の関与を保ったまま、AIの自律性を活かすこともできるはずです。
問題は、AIが自律的に動くことではありません。人間がどこで関与すべきかを決めないまま、AIだけが先に進んでしまうことです。
AI Nativeな働き方では、人間が最後にレビューすればよい、という設計だけでは不十分です。人間が理解可能な単位でAIを使えているか。判断の節目に人間が関与できているか。AIの出力が、人間の認知能力を超えない形で分割されているか。
そこを設計することが、AIを業務に入れていくうえで大事になると思っています。
問題はAIの能力ではなく、タスクの粒度にある
AIに何を任せるかを考えるとき、つい「AIにできるか、できないか」で考えてしまいます。
しかし実務では、「AIにできるか」よりも、「人間がレビューできる形でAIに任せられるか」のほうが大事になる場面が多いと感じています。
AIに大きなタスクを丸ごと渡せば、たしかに見た目の生産性は上がります。自分でゼロから調べるよりも速いですし、資料のたたき台もすぐに出てきます。けれども、その結果を人間が理解し、確認し、必要に応じて修正できないのであれば、それは業務として安定しません。
むしろ、危ないのは「それっぽく整っている」ことです。AIのアウトプットは、見た目がきれイです。構成も整っていますし、言い回しもそれなりに自然です。だからこそ、読む側がなんとなく納得してしまうことがあります。でも、本当に重要なのは、そこに至る前提や判断が妥当かどうかです。
AI Nativeなプロセスでは、AIに任せるタスクの大きさやリスクをコントロールする必要があります。たとえば調査であれば、いきなり最終レポートまで作らせるのではなく、まず論点を出させる。次に調査対象を確認する。さらに根拠を整理させる。そのうえで示唆を組み立てる。そういう段階設計があると、人間は途中で判断できます。
これは、単に慎重にやりましょうという話ではありません。むしろ、AIを業務に深く入れるための設計論だと思っています。AIとの距離が遠すぎると、AIはブラックボックス化します。逆に距離が近すぎると、今度は人間がAIの出力に飲まれます。
必要なのは、AIを信頼することでも、疑うことでもありません。適切な距離で使えるようにすることです。そのためには、プロセスやコンテキスト、あるいはハーネスの設計が重要になります。
ここでいうハーネスとは、AIを縛りつけるという意味ではありません。どちらかというと、高性能なエンジンを業務プロセスに接続するための治具のようなものです。エンジン単体の性能が高くても、車体やブレーキやメーターがなければ、安心して走ることはできません。
AI Nativeな働き方とは、AIエンジンをただ大きくすることではなく、業務として走れる構造に組み込むことなのだと思います。
需要側の期待を満たせているか
もう一つ、最近強く感じているのが、需要側の期待を満たすことの重要性です。
AI利活用の現場では、さまざまな新しい言葉や概念が出てきます。最近だと、Token Maxxingのように、AIの利用量を増やすこと自体に注目する話題もあります。
もちろん、AIを使わなければ何も始まりません。まず使う。たくさん使う。慣れる。これは導入初期には意味があると思います。使ってみないと、何に使えるのかも分かりません。
ただし、使った量がそのまま価値になるわけではありません。たくさんトークンを消費したからといって、業務が良くなったとは限りません。大量のアウトプットが生成されても、それが意思決定や行動に結びつかなければ、現場から見ると「便利そうではあるが、結局何が変わったのか分からない」という感覚になります。
ここには、供給側と需要側のズレがあります。供給側、つまりAIツールやプラットフォームを提供する側は、市場やニーズの拡大を狙います。より高性能なモデル、より長いコンテキスト、より多機能なエージェント、より大量の処理能力。これらは技術の進歩としては自然ですし、必要なことでもあります。
一方で、需要側、つまり実際に業務でAIを使う側にとって重要なのは、必ずしも「どれだけAIを使ったか」ではありません。知りたいのは、何がどう楽になったのか。どの判断が良くなったのか。どの手戻りが減ったのか。どの会議が前に進みやすくなったのか。どの顧客対応が速くなったのか。どのリスクを早く見つけられたのか。つまり、日々の業務の中で、納得できる変化があったかどうかです。
新しい技術の導入フェーズでは、需要側のニーズがまだ十分にモデル化されていないことがあります。そのため、ある程度は供給側が市場を牽引することになります。クラウドでも、スマートフォンでも、SaaSでも、最初は「何に使えるのか」を探しながら市場が広がっていきました。
AIも同じだと思います。ただし、どこかのタイミングで需要側へのシフト、あるいはバランシングが必要になります。供給側の論理だけでAI活用を進めると、「使っている感」は出ても、業務上の納得感がついてこないからです。
意思決定の質の変化に注目する
AI活用の効果をどう測るかという話になると、ROI、KPI、価値創出といった言葉が出てきます。これは当然必要です。企業活動である以上、投資対効果を無視することはできません。
ただ、個人的には、AI利活用の効果をいきなり定量評価に押し込めすぎなくてもよいのではないかと考えています。もちろん、最後には何らかの形で成果を見たい。コストが下がったのか、売上につながったのか、業務時間が減ったのか、品質が上がったのか。そうした評価は必要です。
AI活用の初期段階や、知的作業に近い業務では、効果がすぐに数字として見えないことがあります。ここでいきなり分かりやすい数字だけを求めると、時間削減しやすい業務ばかりが評価されてしまいます。
それは少しもったいない。AIの価値は、単純な作業時間の削減だけではありません。判断の前提を揃えること、論点の抜け漏れを減らすこと、選択肢を増やすこと、反対意見を事前に見つけること、会議の空中戦を減らすこと。こうした効果は、すぐに金額換算しにくいですが、実務上はかなり大きいと思っています。
そこで注目したいのが、意思決定の質です。良質な意思決定とは、単に正解に近い判断をすることではありません。納得感があり、実効性があり、関係者が動ける判断です。判断に至るまでの情報が整理されており、前提が共有され、選択肢とリスクが見えている。だからこそ、決めたあとに動ける。
AIは、この意思決定の質を高めるために使えるのではないかと思います。たとえば、調査の抜け漏れを減らす。論点を複数の角度から洗い出す。反対意見を仮想的に出す。過去の議論を整理する。複数の選択肢のメリットとリスクを比較する。こうした使い方は、直接的な工数削減だけでは測りにくいかもしれません。
しかし、結果として会議の前提が揃い、議論が空中戦になりにくくなり、判断後の手戻りが減るのであれば、それは明らかに価値です。
意思決定の質に注目すると、定量評価の呪縛を少しやわらげることができます。これは、数字で測らなくてよいという話ではありません。むしろ、数字に表れる前の変化を観察するために、意思決定の質を見るということです。
数字にできるものだけを見ると、見えなくなる価値があります。一方で、感覚だけで語ると、今度は組織の中で説明しにくくなります。だからこそ、「意思決定の質」という観点は、その間をつなぐものとして使えるのではないかと思っています。
会議の前提は揃ったか。選択肢とリスクは見えるようになったか。関係者は同じ理解で動けるようになったか。判断後の手戻りは減ったか。こうした変化を見ていくと、AI活用の効果は少し捉えやすくなります。まだきれいなKPIにはならないかもしれません。それでも、現場で「これは効いている」と感じる根拠にはなります。そして、その積み重ねの先に、結果としてのROIが見えてくるのだと思います。
ここで大事なのは、AIに意思決定を任せるという話ではないことです。AIに決めてもらうのではなく、人間がより良く決めるためにAIを使う。これくらいの距離感が、今のところ一番しっくり来ています。
AI Nativeとは、業務を深く見ることでもある
AI Nativeという言葉からは、AIを自由自在に使いこなす姿がイメージされがちです。あらゆる作業をAIに任せ、人間はもっと高度な仕事に集中する。そうした未来像は分かりやすいですし、魅力もあります。
ただ、現時点で感じているAI Nativeな働き方は、もう少し地味です。AIを使えば使うほど、日々の業務に対する理解と解像度が求められるようになります。
なぜなら、AIに任せるには、そもそもその業務が何を目的にしているのか、どこにリスクがあるのか、どの判断が重要なのか、何が成果物として求められているのかを、人間側が理解していなければならないからです。
業務の解像度が低いままAIに依頼すると、AIはそれっぽい成果物を出します。けれども、それが本当に必要なものかどうかは分かりません。むしろ、それっぽく整っているぶんだけ、危ないこともあります。
逆に、業務の構造が見えている人は、AIに適切な単位で仕事を渡せます。前提を与え、制約を伝え、途中で確認し、必要な粒度で成果物を受け取ることができます。
AIを使うことで、その人の業務理解がさらに外在化され、チームに共有されやすくなる。ここに、AI活用の面白さがあると思っています。
つまり、AI Nativeな働き方とは、AIに業務を丸投げすることではありません。業務を分解し、判断のポイントを見極め、AIに任せる部分と人間が握る部分を設計することです。AIが進化すればするほど、人間側にはその設計能力が求められるようになります。
これは少し逆説的です。AIが賢くなるほど、人間は業務を分かっていなくてもよくなるのではなく、むしろ業務をより深く理解している必要が出てくる。AIは魔法の箱というより、こちらの理解度を映す鏡に近いのかもしれません。
少しずつ、AIとの距離感を整える
ここまで考えると、AI Nativeな働き方の中心にあるのは、AIとの距離感の設計だと思います。
AIに任せるタスクの大きさをどう決めるか。どのタイミングで人間が関与するか。どこまでをAIの自律実行にして、どこからを人間の判断に戻すか。どの成果物ならレビュー可能で、どの粒度を超えると人間の認知能力を超えてしまうか。
こうした設計がないままAI活用を進めると、最初は便利でも、徐々に不安定になります。AIが出したものを人間がレビューする、という考え方は重要です。しかし、それだけでは足りません。レビュー可能な単位にタスクを分けること。判断の節目を設計すること。AIの出力を、人間が理解し責任を持てる形にすること。ここまで含めて、はじめて実務に耐えるAI活用になるのだと思います。
需要側の期待を満たすという意味でも同じです。AIをどれだけ使ったかではなく、何がどう解決されたのか。何に納得できるようになったのか。どの意思決定が良くなったのか。そこに目を向けなければ、AI活用は定着しません。
ただ、これはそこまで難しく考えすぎなくてもよい気がしています。いきなり立派なAI Nativeな業務プロセスを作る必要はありません。まずは、自分の仕事の中で、AIに任せすぎると見えなくなるところを探す。逆に、AIに手伝ってもらうと考えが整理されるところを探す。レビューできる大きさにタスクを分ける。途中で立ち止まる場所を作る。それくらいからでよいのだと思います。
2026年6月時点での私の感覚としては、AI Nativeな働き方は、まだ完成された方法論ではありません。むしろ、これから現場ごとに作っていくものだと思います。
ただ、そのときの軸は少し見え始めています。AIとの距離を広げすぎないこと。人間の認知能力を超える形でAIを使わないこと。供給側の利用量ではなく、需要側の納得感を見ること。そして、AI活用の成果を、意思決定の質として捉えてみること。
結局のところ、AIを使いこなすというのは、AIのことだけに詳しくなることではないのだと思います。自分たちの業務を理解し、判断の構造を理解し、どこにAIを入れると意味があるのかを見極めること。その解像度があって初めて、AIは業務の中で本当に効いてくる。
AIを使うほど、結局はこちらが何をしたいのかを問われる。それは少し面倒でもありますが、悪い話ではないと思っています。AI Nativeな働き方は、どこか遠くにある特別な働き方ではなく、日々の仕事の見方を少し変えるところから始まるのだと思います。
コメント