AIモデルを語るのは3流、プロンプトをいじるのは2流、1流は仕組みを変える
はい、どうもこんにちは佐藤です！
この前、スナックで飲んでいたら、隣に座った方にこう聞かれました。
「AI モデルって、何が良いんですか？」
その場は空気を壊したくなかったので、「Claude かなぁ」と答えておきました。ええ、優等生の回答です。おばさんは場を読む生き物ですからね。
でも、帰り道でずっと引っかかっていたんですよ。
本質はそこじゃないんだよなぁ、と。
AI について何を話すかで、その人が AI をどこまで使い込んでいるかは、だいたい透けて見えてしまいます。私の中の勝手な区分けはこうです。
- モデルの話をしているのは 3 流
- プロンプトをいじっているのは 2 流
- 1 流は、業務に革命を起こしている
我ながら失礼な物言いですよね。でも、この差はけっこう本質的なところに刺さっていると思っています。順番に書いていきますね！
3流：モデルにこだわる人は、AI に「察してほしい」だけ
まず、モデルの話です。
「GPT と Claude はどっちが賢いのか」「新しいモデルが出たらしい」。この手の会話が中心になっている人は、失礼を承知で言うと、まだ使い込めていません。
なぜかと言うと、モデルにこだわるという行為の裏側には「指示を工夫したくない」という意図が透けているからです。
考えてみてください。優秀なモデルさえ引き当てれば、雑な一言でいい感じの答えが返ってくる。だからモデル選びが最重要になる。これって、要するに「察してほしい」ってことですよね？
理解ある彼くんを求めているのと同じですよね？
そういう使い方でこなせる仕事には、はっきりと上限があります。
- 英文を翻訳してもらう
- 壁打ち相手として雑談に付き合ってもらう
- 頑張って、手順書のたたき台を作ってもらう
- サイトや長文を要約してもらう
このあたりが関の山でしょう。
もちろん、これでも十分に便利です。実際、翻訳と要約だけでも昔と比べたら魔法みたいなもの。ただ、この使い方は自分の作業が少し速くなるだけなんですよ。業務そのものは、1 ミリも変わっていません。
そして、この層の会話は必ずモデルの品評会になります。使い方の話をする材料が、手元にないからです。
2流：プロンプトは業務の手順書。ここまでは、正しい
次はプロンプトです。
プロンプトエンジニアリングに時間を使っている人は、3 流よりずっと先へ進んでいます。ここは断っておきたいところ。私は、この段階を否定するつもりはまったくありません。
というのも、プロンプトとは業務の手順書そのものだからです。
自分の業務を AI に投げるには、頭の中にあった暗黙の段取りを、言葉にしないといけません。これ、けっこうしんどい作業ですよね。でもそれをやり切っている人は、自分の仕事を言語化できているということです。実は、かなり高度なことをやっています。
業務には必ず手順がありますよね。A をやって、B をやって、C をやる。プロンプトを書くというのは、この順番を明文化する行為に他なりません。
さらに進んでいる人は、フェーズを組んでいます。
A の工程 → チェック → B の工程 → チェック → C の工程 → チェック工程ごとに検証を挟んで、AI の出力が暴走しないように制御する。ここまでやれていたら、もう立派なものです。
ヒューマンインザループってやつですね！
ただ、それでもまだ足りないと私は思っています。
なぜでしょうか。それは、既存の業務フローを前提にしているからです。
A → B → C という手順は、そもそも誰が決めたものでしたっけ。人間だけで仕事を回していた時代に、人間の処理速度を前提として組まれた段取りですよね。そこに AI を差し込んで各工程を速くしても、フローの形は昔のままです。
馬車の馬を速い馬に替えても、それは自動車にはならないのです。
1流：業務に革命を起こせるかどうか
そこで本題です。
**1 流とは、AI を組み入れた仕組みそのものを設計できる人のこと。**もっと踏み込んで言えば、業務に革命を起こせる人です。
判断の軸は、「作業が速くなったか」ではありません。業務のかたちそのものが変わったかです。
考え方の起点はシンプルで、AI をツールではなくメンバーの一人として扱うこと。それも、圧倒的に出力量が多くて、圧倒的に文句を言わないメンバーです。
そうすると、問題設定が変わってきます。「どう指示するか」ではなく、膨大な出力量をどうコントロールするかが主題になるのです。
そして出力量というのは、使い道のあるリソースなんですよ。具体的に見ていきましょう。
フェーズを削る
これまでの開発の流れって、こんな感じでしたよね。
打ち合わせ → 持ち帰る → モックを作る → 確認をとる → 実装なぜ持ち帰る必要があったのでしょうか。モックを作るのに時間がかかったからです。その場で作れないから、宿題にして次回に回していたわけですね。
では、ミーティングの最中にモックを作ってしまったらどうなるでしょう。
持ち帰るフェーズが、消えます。
さらに踏み込むこともできます。そもそもモックというのは、実装が高くつくから間に挟んでいた代用品ですよね。だったら、いきなりフロントの実装をしてしまって、UI ができきった時点で合意をとってもいいわけです。
打ち合わせの往復が消えて、代用品を作る工程も消える。これはもう、作業の効率化ではありません。業務フローの再設計です。
あえてフェーズを増やす
逆方向もあります。ここが面白いところ。
これまで、時間の都合で詳細設計を書かない現場が大多数だったはずです。書いたほうがいいのは全員わかっている。でも、書く工数が出ない。だから飛ばす。よくある話ですよね。
でも AI の出力なら、書く手間は待つだけです。
そうすると、人間は「書く」から解放されて、確認に専念できるようになります。設計レビューという、本来もっとも価値の高い工程に人間を再配置できるわけですね。
フェーズを削るのも、増やすのも、どちらも同じ発想から出てきます。人間がボトルネックになっていた工程を、AI の出力量で組み替えるということ。削ることだけが改善ではないのです。
文脈から判断させて、画面の行き来を消す
保守や運用の自動化も、AI で前提が変わった領域です。
AI の最大の強みは何でしょうか。私は、文脈から判断させられることだと思っています。
これ、従来のプログラミングでは実装工数に見合いませんでした。「この文章はカレンダーへの登録依頼なのか、それとも削除依頼なのか」を判定するために、辞書を作って、ルールを書いて、例外に対応して……。誰がその見積もりを通すんだ、という話ですよね。
いまは、自然言語から意図を判定して、対応するメソッドを回すだけです。
私自身、n8n に噛ませて勤務予定の登録に使っています。メールやチャットのメッセージを情報源にしてしまえば、担当者が画面を行き来する必要そのものが消えるんですよ。作り方は勤怠管理をSlackからできるようにしたら、上司のブルシットジョブが消えた話に書いたので、興味があればそちらもどうぞ。
「入力画面を使いやすくする」ではなく「入力画面に来なくていいようにする」。この発想の差が、まさに革命かどうかの分かれ目だと思っています。
時間の使い方そのものを変える
仕組みを変える対象は、業務フローだけとは限りません。
私は Claude Code Channels を使って、自宅に 24 時間動くサーバーを用意しています。おかげで、どこからでも自分のプロダクトに触れる状態になりました。
机の前に座っている時間だけが開発時間、という制約が外れるわけですね。仕組みを変えるというのは、こういう方向にも効いてきます。
だから、日常会話でレベルはバレる
ここまで書いてきて、冒頭のスナックの話に戻ります。
同じ「AI を使っています」という言葉でも、立ち位置が違えば、口から出てくる話題はまったく別物になります。
| レベル | 会話に出てくる話題 |
|---|---|
| 3 流 | どのモデルが賢いか、新モデルが出たか |
| 2 流 | プロンプトの書き方、指示の工夫、フェーズの組み方 |
| 1 流 | どの工程を消したか、業務がどう変わったか |
だから、いきなりモデルの話をされると、「あー、そんなに使い込んでいないんだなぁ」と感じてしまうわけです。悪気はないんですよ。ただ、材料がそこにしかないことが伝わってきてしまう。
逆に言えば、日常会話でエンジニアとしての AI の使い手レベルはバレます。
これ、けっこう怖くないですか？ 面談でも、商談でも、飲みの席でも。「AI どう使ってます？」の一言で、その人がどこまで踏み込んでいるかが露呈してしまうのです。
気をつけなければね。私も含めて。
まとめ
というわけで、AI モデルの話をしていたら 3 流だよ！って話でした！
あ。正確には、AI で業務のかたちを変えられているか って感じですねっ。
モデル選びが無駄だとは言いません。プロンプトの工夫も、間違いなく必要な段階です。ただ、そこで止まっている限り、変わるのは自分の作業速度だけなんですよね。工程が消えたり、生まれ変わったりはしません。
自分の業務を眺めて、「この工程、そもそも何のためにあったんだっけ？」と問い直すこと。AI 時代に本当に問われているのは、その一点だと思っています。
ぜひみなさんも、業務に革命を起こしてみてください！