生成AIがコードを書き、設計のたたき台を出し、テストやドキュメントまで整えてくれる。そんな時代に、「技術者の仕事はAIに奪われるのでは」と感じる方もいるかもしれません。しかしログミーBusinessの対談「AIが当たり前の時代、人間の価値はどこに残るのか 仕事を詰まらせる"ボトルネック"の正体」では、むしろAIの性能が上がるほど、人間にしかできない「詰まり」の部分がより重要になるという論点が語られています。ITの現場では、もうすでにその変化が起き始めています。本稿では、この論点をIT技術者の視点で噛み砕き、対談ではなく読み物として、何が起きているのか・何を大切にすればよいかを整理します。
関連する視点として、AIは仕事を奪うのか——IT技術者が今、本当に考えるべきことでは「奪う」より「役割が変わる」を、AIでラクになるはずがなぜか忙しい——IT技術者が自分事として考える「仕事が増えるAI活用」ではAI導入で忙しくなるメカニズムを、AI時代に生き残る技術者のTasteとは何かでは評価とレビューの力について扱っています。あわせて読んでいただくと、AI時代の技術者像がよりはっきりします。
「作れる」から「見抜ける」へ——いま、差がつくのはどっちか
以前の開発現場では、仕様を読む、設計する、コードを書く、テストを書く、ドキュメントを書く——この一連の作業のうち、かなりの部分を人間が手でやっていました。いまは、生成AIがかなりの速度でその多くを支援してくれます。
すると何が起きるか。問題の中心が、「作れるか」から「大量に出てきた成果物を、誰が、どう見極めるか」へ移っているのです。
たとえば生成AIに、APIサーバーを作って、Reactの画面も作って、テストコードも書いて、READMEも整えて、エラーハンドリングも追加して——と依頼すると、以前よりはるかに速く「それっぽいもの」が出てきます。その後に必要なのは、次のような作業です。
- そのコードは本当に要件を満たしているか
- セキュリティ上まずい実装はないか
- 例外系が漏れていないか
- 将来の保守性はあるか
- 既存アーキテクチャに整合しているか
- 性能劣化やコスト増大を起こさないか
- 監査や運用に耐えられるか
ここは結局、まだ人間の責任です。つまり、AI時代の現場では、「作る能力」以上に「見抜く能力」 が差になります。コードレビューも、以前の「仲間のコードを確認する」行為から、「AIが量産した成果物を、短時間で正しく評価する」 という色合いがどんどん強くなっていく、と考えると実感に近いと思います。
では、その「見抜く」側に時間がかかってしまうと、どうなるか。対談では、そこにこそ本当のボトルネックがある、という指摘がありました。
遅いのはAIじゃない。「詰まっている」のは人間の側
ログミーの対談では、「人間が仕事を進める上でのボトルネックになっている」 という指摘がありました。AIに大量の成果物を作らせられるようになったいま、大量に作られた成果物をいかに早くチェックできるかが、その人の進み方を左右する。そこに時間がかかってしまうと、もはや人間の側がボトルネックになっている、という感覚です。
言い換えると、「部下としてAIを使う」という認識よりも、自分で詰まらせているから、「早く出さなきゃ」という認識でAIを使うほうが、現場の実態に合っている、という話です。AIは待ってくれません。出てきたものを止めるのも、流すのも、人間の判断です。だからこそ、見極めの速度と精度が、技術者としての価値に直結していきます。
そうなると、もう一つの問いが浮かびます。いまの技術者に、本当に足りなくなるのは何か。
「書ける人」から「任せられる人」へ——実装だけでは足りなくなる理由
「AIにプログラムやコードを全部書かせられるようになっている」——対談のこの一言は、やや極端に聞こえるかもしれませんが、実務感覚としてはかなり本質を突いています。
実際、いまのAIは次のようなものを、かなりの精度で出せます。
- CRUDアプリの雛形
- SQLの生成
- 単体テストの叩き台
- OpenAPI仕様からのコード生成補助
- TerraformやDockerfileの初稿
- ログ整備やリファクタリング案
- 障害原因の仮説整理
つまり、実装の初速は大幅に上がっています。そのため、技術者の価値は「ゼロから全部書けること」だけでは測れなくなります。
むしろ重要になるのは、問題設定が正しいか、AIへの指示が適切か、出力結果を批判的に読めるか、どこを信用し、どこを疑うべきか分かるか、技術的負債を早期に見抜けるか、といった点です。IT技術者っぽく言えば、実装者中心の価値から、設計者・査読者・意思決定者としての価値へ重心が移るということです。コードを書く力は依然として重要ですが、もはや単独では十分条件ではありません。
では、何をAIに任せ、何を人間が担うか——その線引きを、どう考えればよいでしょうか。対談では、ここにもヒントがありました。
楽をするためじゃない。重い判断に集中するためにAIを使う
対談のなかには「脳が疲れることはAIに任せればいい」という趣旨の発言があります。これを雑に受け取ると危険ですが、IT技術者向けに整理すると意味は明確です。
AIに任せやすい仕事の例は、次のようなものです。定型コードの生成、ドキュメントのたたき台作成、テストケース候補の列挙、ログ解析の初期整理、バグ原因の候補出し、会議メモの整理、既存コードの説明文生成、FAQや運用手順書の下書き——いずれも、パターンがはっきりしていて、失敗時の影響が限定しやすい領域です。
一方で、人間が強く関わるべき仕事は、要件の曖昧さを解消する、関係者の利害を調整する、トレードオフを決める、本番影響を判断する、セキュリティ・法務・監査を踏まえて止める、障害時に責任を持って意思決定する、ユーザー体験として本当に妥当か考える——といったものです。
つまり「全部AIに任せよう」ではなく、人間の認知資源を、より高い判断に集中させるためにAIを使うという理解が適切です。楽をするためではなく、より重い判断へ人間を寄せるためにAIを使う、という発想が本質になります。
その「重い判断」や「適切な指示」を、AIに伝えるとき——ここで効いてくるのが、意外かもしれませんが言葉の力です。
「いい感じにして」では伝わらない——技術者の言語化が武器になる理由
対談の前半には、「言葉遊びができる文系の人が強くなる」「表現者の時代が来る」という話があります。IT技術者からすると、少しふわっと見えるかもしれません。しかし実は、AIへの指示の質という意味で、かなり実務的な話です。
なぜならAIは、曖昧な意図を言葉で外部化する能力に強く依存するからです。同じ開発課題でも、AIへの依頼の仕方で結果はかなり変わります。
たとえば「このAPI直して」「いい感じにして」「セキュアにして」では、AIは当たり障りのない答えを返しがちです。一方で、「認証済みユーザーのみ利用可能にする」「RBACはadmin/editor/viewerの3種」「既存のJWTミドルウェアを流用」「レスポンス形式は現行互換」「監査ログを残す」「SQLインジェクション、IDOR、過剰権限に注意」「pytestで正常系／権限なし／存在しないIDの異常系を追加」——のように、条件と文脈を渡せると、出てくる成果物の質が変わります。
ここで必要なのは、単なる日本語力ではありません。抽象化する力、条件を切り出す力、文脈を渡す力、相手に伝わる形に再構成する力です。これはまさに、対談でいう「表現の力」に近いものです。AI時代は、IT技術者にとっても言語化能力がコアスキルになる、という意味で受け止めるとよいでしょう。プロンプト力という軽い言い方より、要件整理・抽象化・構造化の力が問われる、と考えておくと実務に直結します。
一方で、AIに「どう振る舞わせるか」を設計する側に立つとき、別の問いが立ち上がります。AIは本当に中立なのか、という話です。
中立なAIはいない——設計者が決める「どこまで偏らせるか」
対談では、「AIに人格を持たせるほど偏る」という話も出ています。これは、AIをプロダクトとして設計するIT技術者には、かなり重要な論点です。
AIシステムは、完全に中立ではありません。実際には、学習データの偏り、システムプロンプト、ガードレール設計、評価指標、RLHFやポリシー調整、提供企業の思想、ユースケースごとの制約——どこかに価値判断が埋め込まれます。
たとえば社内AIアシスタントを作るとしても、厳格にコンプラ重視にするのか、速度重視で多少自由度を持たせるのか、保守的に答えさせるのか、提案型にするのか、で利用体験は大きく変わります。つまりAIの「人格」は、技術的にはチューニングされた振る舞いの集合です。その人格が強すぎると、特定の観点しか出さない、柔軟な提案ができない、現場判断に不向きになる、利用者の思考を逆に狭める、といった問題が出ます。
教育、医療、金融、行政のような領域では特に、AIにどの程度の価値判断を埋め込むのかが設計責任になります。中立なAIは存在しない、という前提で設計することが大切です。
では、人間にしかできない判断とは、具体的に何か。対談では、ここで「身体性」という言葉が出てきます。ITの現場の言葉に引き寄せると、こういうことです。
ログには出ない「現場の温度」——AIにできない、人間の判断
対談では、人間とAIの大きな違いとして身体性が挙げられています。これをIT技術者向けに言い換えると、AIは世界を「記号として扱う」が、人間は世界を「経験として持つ」 ということです。
たとえば障害対応でも違いが出ます。AIは、ログ、メトリクス、手順書、過去インシデント、一般的ベストプラクティスから、かなり優れた分析を返せます。しかし人間はそれに加えて、現場の緊張感、顧客の怒りの温度、チームの疲弊、組織の力学、「今は正論より止血が先」という感覚、「この担当者は今かなり危ない」という察知——のような、数値化しにくい状況を含めて判断します。この差が、身体性に近いものです。
ITの仕事は論理だけで完結しているようで、実際には顧客折衝、障害時の説明責任、組織内合意、仕様変更時の温度感、チームビルディングのように、人間の感覚が大きく入る領域がたくさんあります。AIが優秀になっても、技術者の現場感覚はむしろ価値が上がる可能性があります。
「いつかAGIが来る」という議論も、対談では触れられています。ただ、今日の設計と運用を考えるうえでは、別の問いのほうが先です。
AGIを待たない。いまのAIで、責任の線を引く
対談の後半では、AGIやASI、Transformerの限界可能性などの話が出てきます。これはおもしろい論点ですが、実務のIT技術者として大切なのは、過度に未来予測へ振り回されないことです。
現場ではまず、いまのAIで何が十分に実用か、どの工程が一番効率化できるか、逆にどこはまだ危険か、検証コストはどれくらいか、人間の責任分界点をどう置くか——といった問いのほうが重要です。
いまのAIは、AGIではなくても十分に強力です。L1サポートの回答補助、社内ナレッジ検索、ソースコード理解補助、テスト作成支援、障害報告書の下書き、非エンジニア向け説明文の作成——こうした用途では、すでに業務インパクトがあります。AGIを待つより、現時点での運用設計・責任設計・評価設計のほうが重要、というスタンスでよいと思います。
ここまで、対談の論点をIT技術者の視点で引き寄せてきました。最後に、「詰まり」が価値になるという一文を、具体的に何に落とし込めばよいか、六つにまとめます。
まとめ——「書く手」より「決める頭」に価値が移る、の本当の意味
AIは、技術者の仕事を奪うというより、仕事の重心をずらしているという理解が大切です。昔は「正しく作れる人」が強かった。これからは 「何を作るべきかを定義し、AIが作ったものを見抜き、責任を持って運用に載せられる人」 が強くなります。
この対談と、IT現場の実感を合わせて整理すると、技術者が実際に学び・伸ばすべきは次の六点です。
レビュー能力の重要性
生成速度ではなく、見極め速度と精度が価値になる。AIを使うほど、レビュー能力が重要になる。
言語化能力は技術力の一部
プロンプト力というより、要件整理・抽象化・構造化の力が問われる。
認知資源の再配分が本質
単純作業の削減ではなく、より重い判断へ人間を寄せるためにAIを使う。
責任主体は人間に残る
特に本番運用、セキュリティ、法令順守、説明責任は人間側に残る。AIは便利でも責任主体にはなれない。
中立なAIは存在しない前提で設計する
AIの出力は、モデル、ルール、企業方針、評価設計に左右される。
価値は「書く手」より「決める頭」に寄る
何を作るか、なぜ作るか、どこで止めるか、どのリスクを受け入れるかが本丸になる。設計力、批判的思考、レビュー力、文脈理解、意思決定力、説明責任を果たす力が、AI時代のIT技術者に求められます。
AIの性能が上がるほど、技術者の仕事は減るのではなく、「人間にしかできない詰まり」の部分がより重要になる——この一文を、日々の設計・レビュー・意思決定のなかで思い出していただければ幸いです。
作成日：2026年3月9日