中小企業診断士・ITコーディネータの大澤真介です。
合同会社オンザウェイの代表をしています。
「”やりたい”を”できている”に変える実装支援」をテーマに、中小企業のご支援に取り組んでいます。
最近、ちょっとした違和感を抱えながら仕事をしています。
もしかして、足を引っ張っているのは自分自身なんじゃないか─そんな感覚です。
Claude CodeやAIとの対話で何かを作るとき、コードは、わずかな時間で形になります。テストも、ユニットテストは AI に書かせられるし、ブラウザでの動作確認は Claude in Chrome に代行させられる。
個別の作業は確かに速くなっています。
なのに、開発全体として「速くなった」感覚があまりありません。
なぜか。
種明かしをすると、AI で速くなる工程の前後──つまり、「何を作るか決める」工程と、「人間が実際に使ってみる」工程で時間が取られていて、ここが今、私の中での詰まりになっているからです。
ここ最近、私はこの感覚を「HITL（ヒューマン・イン・ザ・ループ）が詰まっている状態」だなと、客観的に自分自身を眺めています。
AI 活用が進めば進むほど、AI で速くならない作業が相対的に膨れ上がってくる現象です。
リアルタイムで悩んでいるテーマなので、現時点で考えていることを正直に書きます。
AIで速くなったのは、開発の真ん中だけ
「2026年、中小企業は『自分専用のツール』を自分で作る時代へ」でも書いたとおり、生成 AI の登場で「自分でツールを作る」ハードルは大きく下がりました。
Claude Code のようなコーディングエージェントを使えば、要件を渡してから動くものが出てくるまでのスピードは、以前の比ではありません。
ただ、ここで一つ落とし穴があります。
実装は速くなった。けれど、その前後は速くなっていない。
開発の流れをざっくり書くと、こうなります。
①要件定義・設計 → ②実装 → ③テスト → ④人間が使ってみる
人間がやる AIで速い 一部AIで速い 人間がやるAI で劇的に速くなったのは ② の実装。
③ のテストも、ユニットテストやブラウザの E2E テストといった機械的に自動化できる部分は AI に任せられるようになりました。
ところが、① の要件定義と、④ の「実際に人間が使ってみる」部分は、AI では速くなりません。
むしろ、AI に作業を渡すために厳密な言語化が必要になること（しっかりとした定義ができていない場合には膨大な手戻り）、自分のスキルでは実装できないものがAIに手伝ってもらうことで可能になる。
要件定義の時間は増えている感覚すらあります。
詰まりポイント①──要件定義と設計
Claude Code に「○○を作って」と言えば、AI は作ってくれます。
ただし、それは「私が言ったとおりのもの」を作ってくれるだけです。「私が本当に作るべきもの」を作ってくれるわけではありません。
そして、自分の頭の中にある「作りたい」を、AI に伝わる粒度まで言語化する作業は、まったく自動化できません。
AI に渡す時点で曖昧さを極力排除したい。自動化したければなおさら。
自分でゆるく考えていた頃よりも、むしろ厳密に決める必要があります。
たとえば「お客さんからの問い合わせ管理ツールを作りたい」と思ったとします。これを Claude Code に渡すには、
- どんな項目を持たせるか（氏名、連絡手段、案件の段階、対応履歴、など）
- どこにデータを保存するか（スプレッドシート、Firebase、Notion、など）
- 誰がアクセスできるか
- どのタイミングで通知が必要か
- 似た問い合わせをどう紐付けるか
このあたりを、ある程度まで決めてから渡す必要があります。
決めずに丸投げすると、AI は無難な「それっぽいもの」を作って返してきます。動くけれど、自分の業務には合わない。結局、後から手戻りで修正することになる。
つまり、「Claude Code でツールを作る速度」は、コードを書く速度ではなく、要件を固める自分の速度で決まるということです。
ここに、自分が思っていた以上に時間が取られています。
ちなみに、要件定義の方も「全部、自分の頭の中だけで決める」をやめようとしています。
最近は、決めきる前にAIを壁打ち相手にして、抜け漏れや矛盾を指摘してもらう。
決めるのはあくまで自分ですが、思考を一段階早く前に進めるための補助輪としてAIを使うイメージです。
これだけでも、要件の固まり方が早くなる感触はあります。
詰まりポイント②─機械テストはAIに任せられる。でも、人間テストは私から離せない
もう一つの詰まりは、テスト工程の後半、つまり「人間が実際に使ってみる」の部分です。
私は日々の仕事の中で、Claude Code や Cursor を使って、自社のサービスやクライアント向けの小〜中規模のツール開発を進めています。
ユニットテストはAIに書かせています。
コードのロジックレベルの検証は、これでだいぶカバーできます。
さらに、ブラウザでの動作確認も、最近は Claude in Chrome を使って画面遷移やボタン操作の確認を AI に代行させられるようになりました。
ここまでは AI に任せられます。
ところが、その先─「お客さんがこの画面を見て、このボタンを押したときに、想定通りの体験になっているか」を確認する作業は、結局、人間が時間を取って触ってみるしかありません。
- 文言が分かりにくくないか
- 入力中に違和感を覚えないか
- 想定外の操作をしたときに、変な挙動にならないか
- スマホで開いたときの見た目はどうか
- 数日使い続けて、ストレスが溜まらないか
このあたりは、テストコードでは捕まえきれません。AI に「ユーザー体験を評価して」と頼んでも、ユーザーが本当にどう感じるかの判断は、AI には下せない部分が残ります。
私が一番嫌いなこと「せっかく導入したけど使っていない・使いたくない」。コンサルタントとして開発者として一番言われたくない言葉です。
そして、最終的に「これで世に出していいか、クライアントに納品して良いか」を判断するのは、ほかの誰でもなく私です。
ここはどうしても私の手から離せない。
離してしまうと、それは「自分が関わったものを世に出す責任、お金をもらう責任」を放棄することになります。
つまり、私自身がボトルネックになっているのは、能力や怠慢の問題ではなく、役割としてここを引き受けるしかないからなのだと、最近ようやく整理がついてきました。
なぜ AI 活用が進むほど、ここが詰まるのか
ここまで書いて、構造が少し見えてきました。
AI で速くなる作業（実装、機械的テスト）と、AI で速くならない作業（要件定義、人間テスト）が混在している中で、片側だけが速くなる。すると、相対的に速くならない側が太く見えてくるわけです。
水道のホースを思い浮かべてください。途中の太い管をどれだけ太くしても、入口と出口が細ければ、流れる水の量はそこで決まります。AI で真ん中が太くなった結果、入口と出口の細さが、急に目立ってきた──というのが、今の感覚です。
「全部、自分で触る」前提も、たぶん見直しが要る
人間テストについて、もう一つ自分に問い直していることがあります。
「全部、自分で触ってみる」は本当に必要か？という問いです。
以前の私は、機能を作ったら全画面・全動線を自分で触って確認していました。けれど、最近の改修頻度を考えると、これはもう物理的に追いつきません。
なので、人間テストも「全件」ではなく、
- お金や数字が動く動線（決済・請求・計算結果）
- データが書き換わる重要な処理
- 初めてのお客さんが触る画面
このあたりに絞って、深く触る運用に切り替えようとしています。それ以外は機械テストとお客様からのフィードバックに任せる。
完全に納得しているわけではありませんが、現状の手数を考えると、ここに振らざるを得ない。
これは、以前書いた「全部追いかけなくていい」と書いた私が、裏でやっていたことの構造と、たぶん同じです。
AI で速くなる時代は、「全部やる」前提から降りる勇気が、思っていた以上にいろんな場面で求められる気がしています。
「実装の壁」を越えた先に、新しい壁があった
ここまでは私個人の悩みとして書いてきました。けれど、これは「自分専用のツールを作る」流れに入りつつある中小企業にも、同じことが起きる話だと思っています。
私はずっと、中小企業の「実装の壁」─戦略と実行の間にある、構想したものを形にできない壁─を越えるお手伝いをしてきました。
生成AIの登場で、その壁は確かに低くなりました。Claude Code のようなコーディングエージェントを使えば、プロのエンジニアでなくても、形にすること自体は出来るようになっています。
ところが、その壁を越えた先に、新しい壁が現れた。
「何を作るかを言語化する壁」と「出来たものを自分で使い切る壁」です。実装が速くなったぶん、この2つの壁の高さが急に目立ってきました。
そしてこの2つは、AI では肩代わりできません。
- 自分の業務に何が必要かを言語化する力
- 出来たものを実際に使ってみて、合うか合わないかを判断する目
むしろ、AI で「作る」が速くなるほど、この2つの相対的な価値が上がります。裏を返すと、**「AI に任せられないところに、自分の時間と手数を残せるかどうか」**が、中小企業の AI 活用が前進するかどうかの分かれ目になる気がしています。実装の速さに目を奪われていると、ここを見落とす。
まとめ─実装が速くなった分、要件定義と人間テストの「時間設計」を組み直す
開発の HITL ボトルネックは、実装そのものではなく、その前後にあります。
- 何を作るか決める時間
- 出来たものを自分で使ってみる時間
ここは AI に任せられませんし、たぶんこれからも任せきりにはできません。だからこそ、AI で実装が速くなった分、この前後の作業に時間を意識的に振り分け直す必要があるのだと思います。
正直に言うと、私自身もまだここを綺麗に組み直せていません。要件定義と人間テストの両方で、まさにその真っ只中でもがいています。それでも、足を引っ張っているのが何なのか、その場所が見えただけで、対処の方向は少し見えてきた感覚があります。
しばらくの間、要件定義の時間の取り方と、人間テストの絞り込み方を試行錯誤してみるつもりです。手応えが見えてきたら、また書きます。
「Claude Codeで作ってはみたけど、思ったように業務に乗らない」「AIで作るのは速いのに、検証が追いつかない」──最近、こうしたご相談が増えています。
要件定義の固め方、テスト設計、リリースまでの組み立て方を、業務に合わせて一緒に整理させていただきます。
この記事はnoteでも公開しています。
実装支援・DX推進・生成AI活用のご相談は、お気軽にお問い合わせください。
→ お問い合わせはこちらから