6合目を、山頂と呼んでいないか。
AIで「作る」が終わった先の、正しいリープフロッグ

前回、「安くなったのは『作る時間』だけだった」という記事を書いた。AIによって作る技能はコモディティ化し、デジタル人材の価値は「作る力」から「決める力」へ移った——という話だ。

今回はその続きになる。価値が移ったあと、ではどう跳ぶのか。

第1部｜順番は、遅れている側に回ってきた

想定より、一年ほど早かった

私はこの連載で一貫して「手段はコモディティ化する」と書いてきた。EC基盤の選定でも、基幹システムのRFPでも、クラウド移行の判断でも、結論は同じだった。作ること自体は安く速くなり、差を生むのは選び方のほうへ移る、と。

正直に書くと、想定より早い。

次期基幹の設計フェーズで、私は発注者側からAI駆動開発（AIDD）を契約に明記した。当時、社内でも社外でも「挑戦的だ」と言われた。挑戦だと自分でも思っていた。それが一年と経たずに、挑戦ではなく前提になった。いまや「AIを使わずに作ります」という提案のほうが、説明を要する。

この速度は、私の予測が甘かったという以上の意味を持っている。変化が速いということは、これまでの遅れが持つ意味も変わるということだ。

AIが安くしたのは、3段のうちの2段目だけだった

経済産業省の「DXレポート2」は、デジタル化の取り組みを3つの段に分けて整理している。

中小企業が長年つまずいてきたのは、2段目である。しかも、つまずきの原因は予算ではなかった。手を動かせる人と、要件を言語化できる人と、社内を説得できる人を、同時に揃えられないことだった。一人で三役をこなせる人材は、そもそも中小企業の給与レンジでは採れない。だから多くの会社が2段目の入口で止まり、3段目の議論に辿り着かないまま10年が過ぎた。

生成AIが崩したのは、この2段目の壁である。

試作、帳票、集計、文書化、データ変換——以前なら外注していた規模のものが、社内で動く。もっと言えば、2段目を「作業として」順番に登る必要がなくなった。紙をデータにしてから業務を作り直す、という順序は、AIが両方を同時に引き受けられる以上、必然ではなくなった。

これがリープフロッグの成立条件だ。固定電話網を敷かないまま携帯電話網へ跳んだ新興国と、構図は同じである。段を順に積む必要があるとき、後発は不利になる。段を飛ばせるとき、後発の不利は消える。

逆説——守るべきものがない会社が、いちばん軽い

そしてここからが、この記事で最初に言いたいことだ。

IT化が進んでいる会社ほど、跳ぶときに重い。

私が発注者側で見てきた「重り」を、具体的に挙げる。

• 10年分のカスタマイズ。 私が関わったEC基盤では、パートナーが実装したカスタムアプリのドラフトオーダー処理が、Shopify標準のPOS機能を殺していた。追加したものが、標準機能を潰していたのだ。作り込みは資産のように見えて、次の一手を封じる。
• 既存ベンダーとの関係と、そこに紐づいた人間関係。 技術的な判断であるはずのものが、いつのまにか「あの会社に長く世話になっている」という話になる。
• 「今の帳票と同じでないと現場が困る」という互換要求。 帳票の見た目を維持するためだけに、非合理なデータ構造が引き継がれていく。
• 教育投資の埋没コスト。 「この操作を覚えるのに3年かかった」は、変えない理由として驚くほど強い。
• 部門ごとに最適化されたExcelという名の既得権。 これが一番手強い。誰の目にも見えないところで、業務の実体を握っている。

さらに、クラウド移行の現場では、12年放置された認証基盤と「全員同じパスワード」という現実に出会った。「重要データの置き場」と説明された共有サーバーを開けたら、何が入っているのか誰も把握していなかった。「複雑だから残したい」と言われたものは、たいてい逆——複雑だから捨てるべきものだった。

これらは全部、すでにIT化してしまった会社の話である。

IT化が遅れているとは、この重りを一つも背負っていないということだ。守るべき依存関係がない。維持すべき継続性がない。互換性を保つべき過去がない。負債がないことは、この局面に限り、明確な資産である。

ただし——ここで話を止めると、危ない

多くの記事はここで終わる。「遅れているあなたにこそチャンスがある」と。

だが、負債がないことは「跳ぶコストが低い」という意味しか持たない。跳ぶ理由にはならないし、跳ぶ方向を教えてもくれない。

そして忘れてはいけないのは、跳ぶコストが下がったということは、間違った方向へ跳ぶコストも下がったということだ。安く速く跳べるということは、安く速く、見当違いの場所に着地できるということでもある。

跳躍には、着地点が要る。

第2部｜コモディティ化したのは、「作る」だけだった

作ることと、解決することは、別の行為だ

会議で最も頻繁に聞くようになった一文がある。

「AIがあるんだから、その課題は解決できるでしょう」

この一文には、二つの飛躍が隠れている。ひとつは「課題が正しく特定されている」という前提。もうひとつは「作れば解決する」という前提。

課題解決は、少なくとも三工程からなる。

1. 課題を正しく特定する
2. 解決手段を見極める
3. 作る

AIが引き受けたのは、3だけである。 1と2は、一円も安くなっていない。むしろ、3が安くなったぶんだけ、1と2の相対的な重みは上がった。

にもかかわらず、体感としては逆に見える。デモを見れば「解決している」ように見えるからだ。それらしい成果物は、驚くほど速く出てくる。ここに疑いはない。問題は、その出力を自分で評価できるかどうかだ。

優秀な通訳がいても、商談は成立しない

リアルタイム翻訳を思い浮かべてほしい。

いまや、言語の壁はほとんど消えた。海外の取引先と、流暢に会話が成立する。相手は頷き、返答が返ってくる。だから「通じた」と判断する。

だが、次の三つは翻訳では埋まらない。

第一に、自分が何を合意しに来たのか分かっていなければ、流暢に的外れが伝わるだけだ。 通訳が優秀であればあるほど、的外れは正確に、よどみなく相手に届く。

第二に、相手の返答が「YES」に聞こえても、それが無条件のyesなのか、条件付きのyesなのか、社交辞令のyesなのかは、判定できない。 判定には、その業界の商習慣と、交渉の文脈と、相手の立場の理解が要る。通訳はそこまでは訳さない。

第三に、通訳は「あなたの要求は無理筋です」とは言わない。 忠実に訳すのが仕事だからだ。

つまり——会話が成立したことは、正しく伝わったことの証明ではない。

AIの出力も、まったく同じ構造にある。動くコード、整ったスライド、それらしい分析。いずれも「通じた」ことの証拠にはなるが、「正しい」ことの証拠にはならない。そして評価能力がない状態では、何を出しても成功体験になってしまう。

さらに厄介なのは、AIが従順であることだ。「この方式で行きたい」と言えば、その方式で最善を尽くしてくれる。前提そのものが間違っていても、だ。ここにハルシネーションが加わると、「間違った前提のまま、破綻なく完成した成果物」が生まれる。破綻していないから、レビューをすり抜ける。

ダニング＝クルーガーは、「誰に」ではなく「どこで」起きるかが問題

自己評価と実力の乖離——ダニング＝クルーガー効果は、AI活用において構造的に発生する。出力の質を見分ける力がない段階では、何を聞いても成功体験になる。だから自己評価が上振れる。これは能力の問題ではなく、構造の問題であり、誰にでも起きる。私自身にも起きる。

ここで重要なのは、誰が愚かかという話ではなく、どこで起きるかという話だということだ。

• 若手に起きた場合——レビューで補正される。損失は学習コストに収まる。
• 決裁権を持つ人に起きた場合——それは「判断」になる。組織の方向が変わる。そして補正機構が存在しない。

そして残酷なことに、AI活用の自己評価の精度は、役職や経験年数と相関しない。むしろ上位層ほど「うまくいったデモ」に触れる機会が多く、「うまくいかなかった実装」に触れる機会が少ない。構造的に、上に行くほど上振れやすい。

私が「AI段位検定」という仕組みを作った動機は、まさにここにあった。「かなり使いこなせています」と言う人と「まだ全然です」と言う人のAI活用が、実測すると逆転していることが珍しくなかったからだ。

そして、「IT人材の軽視」が始まっている

この乖離が組織に及ぼす最も深刻な影響が、これだ。

「AIでできるのに、なぜそんなに時間がかかるのか」

この問いへの変換が起きると、圧縮できないと分かっている工程まで、圧縮を要求される。

• 業務をヒアリングして構造を掴む工程
• データの整合性を担保する、地味で終わりのない作業
• 関係者の合意を取る往復

これらはすべて、技術ではなく合意の問題だ。実務の肌感覚で言えば、プロジェクト全期間の6〜7割はここに消える。そしてAIが来たあとも、この比率は動いていない。 分母が縮んだぶん、比率はむしろ上がったとさえ言える。

にもかかわらず、手段が安くなった分だけ、決める工数まで一緒に値引きされる。論理的には無関係なのだが、「全体的に速くなったはずだ」という体感が、内訳を無視して全部にかかる。 だから、抵抗しにくい。

はっきり書く。いま多くの組織で意思決定を最も歪めているのは、決裁権を持つ人の自己評価の上振れである。

そしてこれが厄介なのは、悪意も怠慢も介在しないことだ。むしろ熱心な人ほど陥る。自分で触ってみて、動くものが出てきて、可能性を確信する。その確信は正しい——ただし「作る」の範囲においてのみ正しい。範囲の限定に本人が気づけない、というだけの話だ。

その結果、会議室では「時間がかかる」という主張が、常に不利になる。慎重論は、それが正しいときでさえ、遅い人の言い訳のように聞こえる。 そして声の大きさは、たいてい役職に比例する。

繰り返すが、誰かが悪いという話ではない。構造的にそうなる。だから対策も、個人の勇気や反省ではなく、仕組みの側に置くしかない。 第5部で、その仕組みを一つ提案する。

第3部｜山に登るのか、海に行くのか

ここまでの話を、一つの比喩に集約したい。この比喩が、この記事で最も伝えたい部分だ。

判断には、三つの層がある。

層1：行き先——AIは、どこへ行くかを決めない

「AIで何かできないか」

この問いは、「とりあえず、どこかへ行きたい」と言っているのと同じである。

山に登るのか、海に行くのか。それは事業の話であって、技術の話ではない。売上を伸ばしたいのか、人手不足を解消したいのか、属人化を解きたいのか、粗利率を改善したいのか。目的が違えば、必要な装備も、かかる時間も、成功の定義も、すべて変わる。

AIにとっての世界は、プロンプトに書かれた範囲が全部だ。書かれていない目的を、AIが補ってくれることはない。

そして本当に怖いのは、行き先を決めずに出発しても、AIは何かしらの場所へ連れて行ってくれることだ。だから「進んでいる感覚」だけは確実に手に入る。PoCを量産して組織が疲弊する現象の正体は、これである。動いてはいる。ただ、どこへ向かっているかを誰も定義していない。

層2：標高——高さを知らなければ、着いたかどうかを判定できない

ここが核心だ。

山頂の標高を知らないまま登ると、どうなるか。

6合目の、見晴らしのいい場所で「着いた」と思う。

眺めはいい。登ってきた実感もある。息も切れている。だから旗を立てて、写真を撮って、報告する。

組織で起きているのは、まさにこれだ。

ある部署が、AIで在庫確認のツールを作る。作業時間は本当に減る。数字も出る。だから報告は通る。

通ったあとで、誰も問わない問いが残る。そのツールが表示している在庫数は、何を根拠にした在庫数なのか。 出荷指示を出した時点で引き当てているのか、実棚の数字なのか。隣の部署が見ている在庫数と、同じ定義なのか。

私の経験では、ここで数字が割れる。そして割れていることに、しばらく誰も気づかない。両方とも「正しく動いている」からだ。

AIは、指示された範囲を最適化することにおいては完璧だ。だが、その範囲が正しいかどうかは、指示した人間しか知らない。 範囲の外側にある事情——他部署の運用、過去の経緯、来期の商流の変更予定——は、プロンプトに書かれていない。書かれていないものは、AIにとって存在しない。

6合目で旗を立てると、二つの損害が出る。

損害①：山頂に着いていないのに、着いたことになる。 本当の課題が未解決のまま、予算と関心が終わる。次に同じテーマを提案しても「あれはもう去年やった」と言われる。

損害②：後から山頂の存在に気づいて、登り直すことになる。 二度手間だ。しかも、一度立てた旗を抜くのは、立てるよりはるかに難しい。「あれは成果だった」と、すでに報告済みだからである。

だから、登る前に標高を数字で決める。 「作業時間が減ったら成功」ではなく、「どの数字が、いつまでに、いくつになったら山頂か」を先に置く。完了条件を後から作ると、それは必ず「到達できた地点」に合わせて書かれる。

私が次期基幹の設計で痛感したのも、この順序だった。個別のシステムは、どれも担当部署から見れば優秀だった。誰も手を抜いていない。それでも全体は繋がらなかった。 各部署がそれぞれの6合目に、それぞれ正しく到達していたからである。

部分最適を積み上げても、全体最適にはならない。 これは足し算が成り立たないという話ではなく、そもそも測っている尺度が違うという話だ。標高を全社で一本に決めておかなければ、各自が自分の到達点を山頂と呼ぶ。それが構造的に起きる。

層3：装備——標高を知らないと、酸素ボンベを持たずに登る

標高3,000mの山と8,000mの山では、必要な装備がまったく違う。そして装備の判断は、標高の認識からしか出てこない。 高さを見誤れば、必ず装備を見誤る。

ITにおける酸素ボンベは、だいたいこの四つだ。

• 全社で一意のマスタとID。 これがないまま登るほど、標高が上がるにつれてデータが分断していく。
• 認証と権限、そしてログ。 誰が、何に、なぜアクセスしたのか。
• データの出口。 顧客情報が、どの外部サービスに、誰の許可で渡っているのか。
• 引き継ぎ手。 作った人が異動したあと、誰が直すのか。

ここで、これまでの常識が一つ壊れていることを指摘しておきたい。

かつて、装備の点検は、登山の技術と不可分だった。 動くものを作れる人は、必然的に作法も知っていた。認証をどう通すか、権限をどう切るか、他システムに何が波及するか——これらを理解していなければ、そもそも動かせなかったからだ。技術的なハードルが、結果としてガバナンスの門番を兼ねていた。

その門番が、いなくなった。

いまは、作法を一つも知らないまま、動くものが作れる。つまり、装備の知識がゼロの人が、標高だけを上げられるようになった。

登山でいえば、ロープの結び方も高山病の症状も知らない人が、ヘリで7合目に降ろされるようなものだ。本人の感覚では、順調に来ている。実際、そこまでは順調だった。問題は、そこから先が全部「自力」であることと、自力で行ける範囲を判断する材料を、本人が持っていないことのほうにある。

シャドーITは、これまで「詳しい人」しか作れなかった。いまは誰でも作れる。作った本人に悪意はない。ただ、意識する必要がなかっただけだ。そしてAIは、こうした負債を作る速度を、桁で上げてしまう。

ガイドが優秀でも、行き先を知らないパーティは遭難する

AIは、極めて優秀なガイドだ。ルートを知っている。荷物を持ってくれる。疲れない。何度でも登り直してくれる。

だが、AIは「どの山に登りたいですか」とは聞いてこない。聞いたとしても、答えるのは依頼者のほうだ。

そして——ガイドは、依頼者が6合目で「着きました」と言えば、それを否定しない。

第4部｜デジタル人材を、定義し直す

旧定義は、すでに崩れている

「デジタル人材が足りない」と、この10年ずっと言われてきた。だが、足りないと言われていたものの中身を、あらためて確かめておきたい。

求人票に書かれていたのは、おおむね「ツールを扱える人」だった。SaaSに明るい、ノーコードで組める、SQLが書ける、データを触れる。要するに手段の側の能力である。

その要件は、いまや誰でも満たせる。だから「デジタル人材が足りない」という言葉は、意味を失ったのではなく、指す対象を失った。足りないものは確かにあるのに、それを指す言葉のほうが古いままなのだ。

では、いま本当に足りていないものは何か。私は三つの要件で整理している。そしてこの三つは、先ほどの登山の三層に、そのまま対応する。

要件①：知識体系（ドメイン知識）＝ 標高が分かること

自社の業務・商流・組織・そこに至った履歴を、構造として理解していること。

なぜ必要か。AIの出力が目標どおりのものかを判定できるのは、これだけだからだ。

翻訳を検証できるのが元々その言語ができる人だけであるのと、まったく同じ理屈である。「それらしいもの」と「正しいもの」を見分ける基準は、ドメインの中にしかない。そして全体像は、決してプロンプトには書かれていない。その会社の中にしか存在しない。

注意すべきは、これが「業界に長くいる」とは違うということだ。長くいても、自分の工程しか知らない人は、標高を知らない。構造として理解しているかが問われる。

要件②：情報アップデート ＝ ルートと装備が分かること

技術の選択肢がいま何であり、どこまで来ているかを、更新し続けていること。

なぜ必要か。最適な技術選択は、選択肢を知らなければできないからだ。

そしてこの領域は、陳腐化が最も速い。去年の最適解が今年は割高、ということが普通に起きる。私自身、連載を書き始めた時点の技術前提が、書き終える前に変わった箇所がいくつもある。

ただし、ここは誤解されやすい。「新しいツールを知っている」ことと、「選択肢の中から自社の制約に噛み合うものを選べる」ことは違う。 前者はAIに代替された側の能力であり、後者は代替されていない。知っているだけの人は、実は最も危うい。知っているツールに業務を当てはめるという、逆順の作業をしてしまうからだ。そして逆順の作業は、AIがいちばん得意な領域である。

要件③：ソリューション想定 ＝ 登った価値が分かること

できあがったものが、工数削減になるか、利益になるか、人が使いやすくなるかを、作る前に想像できること。

なぜ必要か。作れる速度が上がったいま、「作ってから考える」が最も高くつくからだ。

作れなかった時代は、作る前に考えざるを得なかった。外注費が高く、期間が長かったから、制約が思考を強制していた。いまその制約が外れたぶん、想像力を自前で持つ必要がある。

そして「使いやすくなるか」を軽視してはいけない。現場が使わないツールは、工数削減にも利益にもならない。存在しなかったのと同じ——いや、保守コストがかかるぶん、存在しなかったより悪い。

そして最後に、決断が要る

三要件を満たしても、まだ足りない。

分かることと、決めることは、別だ。

• 課題が分かる人は、これから増える。AIが分析を手伝うからだ。
• 解決方法を見極められる人も、増える。AIが選択肢を並べてくれるからだ。
• だが、「これでいく」と決めて、外れたときに責任を引き受ける人は、増えない。

AIは決断しない。決断とは、選ばなかった選択肢を捨てることであり、外れたときに責任を負うことだからだ。この二つは、原理的にAIには引き受けられない。

だから私は、こう言い切る。AIコモディティ時代に最も希少なのは、優秀な作り手ではない。捨てられる人だ。

第5部｜提言：正しいリープフロッグの、五つの最低条件

「跳べる」と「跳ぶべき」は違う。以下の五つを満たさないまま跳ぶことを、私は勧めない。

条件1｜跳ぶ先を、経営と現場が「同じ絵」で見ていること

決める速さにおいて、中小企業は大企業より構造的に有利だ。決裁の階層が浅く、経営者と現場の距離が近く、稟議の経路が短い。これは規模では買えない強みである。

ただし、それは潜在的な優位でしかない。 経営層が「決めた」と考え、現場が「聞いていない」と答える状態では、決定は現場で止まる。方針は存在するのに、機能しない。

そして最も厄介なのは、揃っていないこと自体が、たいてい自覚されていないことだ。経営層は伝えたつもりでいる。現場は聞いていないと思っている。両方が本気でそう思っている。

決裁が速いことは、伝わっていることを意味しない。 跳躍は、経営者一人が跳ぶ先を見ている会社ではなく、経営と現場が同じものを見ている会社にしか起きない。

条件2｜山頂を、数字で定義すること

「AIで効率化する」は、行き先ではない。

何の数字が、いつまでに、いくつになるのか。それを作る前に、決裁者本人の言葉で書く。

完了条件を後から作れば、それは必ず「到達できた地点」に合わせて書かれる。つまり、6合目に旗が立つ。これは意志の弱さではなく、人間の認知の仕組みだ。だから順序で防ぐしかない。

条件3｜飛ばせるのは「作業」であって、「合意」ではない

ここが、リープフロッグ論で最も誤解される点だ。

飛ばせるのは、紙をデータにする作業や、業務をシステムに置き換える作業である。

飛ばせないのは、こちらだ。

• 顧客コードを、どう統一するか
• 表記揺れと同姓同名を、どう扱うか
• 誰が最終承認するのか
• この数値を「正しい」と言える責任は、誰が持つのか

段は飛ばせても、合意は飛ばせない。 そして合意形成は、AIが来ても一円も安くなっていない。むしろ「作る」が速くなったぶん、合意していない部分が、より速く形になって表面化する。

DXが進まない理由は、「作れないから」から「決まらないから」へ移った。リープフロッグとは、決まらない問題を飛ばすことではなく、決まっている前提を最短で形にすることだ。

条件4｜装備点検を、「着手条件」にすること

作ってから権限を考えるのではなく、作る前に決める。最低限、この四つは着手条件に置く。

1. データの出口——どの外部サービスに、何が渡るのか
2. 認証と権限——誰が、何に、なぜアクセスできるのか
3. ログ——後から誰が何をしたか追えるか
4. 引き継ぎ手——作った人が抜けたとき、誰が直すのか

これは「慎重にやろう」という話ではない。逆だ。作る速度が上がったぶん、装備不足が露呈するまでの時間も短くなったという話である。速く登るなら、装備の確認はより手前に置く必要がある。

条件5｜「AIでできるでしょう」に、範囲を問い返す仕組みを組織に置くこと

個人の勇気に依存させてはいけない。役員会で上位者にそれを言い返せる人は、組織にほとんどいない。

だから、仕組みにする。提案書や起案の様式に、一行入れるだけでいい。

この施策は、どこまでの範囲で最適か。範囲外に、しわ寄せは出ないか。

たったこれだけで、部分最適が「DXの進捗」として無審査で通過する確率は、目に見えて下がる。書く側が自分で気づくからだ。声の大きさで議論が決まる構造を、様式で中和する。 これが最も安く、最も効く。

結び｜跳べることは、跳ぶ理由ではない

跳べる時代になった。これは本当だ。そして遅れている会社ほど軽いのも、本当だ。守るべき依存も、継続性も、互換性もないことは、この局面において明確な優位である。

だが、軽さは跳ぶ理由ではない。行き先を決める仕事は、いつも人間の側に残る。

山に登るのか、海に行くのか。
その山は、何メートルか。
酸素ボンベは、要るのか。

AIは、この三つの問いに答えない。 答えられるのは、自社の業務を誰よりも深く理解していて、かつ「自分がどこまで分かっていて、どこから分かっていないか」を正確に知っている人だけだ。

過大評価は学びを止め、過小評価は挑戦を止める。そしていま、組織の意思決定を最も歪めているのは、決裁権を持つ人の過大評価のほうである。

「AIでできるでしょう」と言われたとき、一度だけ、立ち止まって問うてほしい。

「それは、どこまでの範囲で最適なのですか」

評決ではなく、レンズを。手段が横並びになるほど、散らばった知識の“点と点”をつなぎ、自社の本質——何を、どの基準で選び、何を捨てるかを見極める力が問われます。私はアトムビットとして、その見極めを特定ベンダーに肩入れしないフラットな評価軸でお渡しします。売るのは「どれが一番か」という評決ではなく、「あなたの制約でどう選ぶか」というレンズです。最終選定と結果責任は、いつも発注者にあります。