まだ「生成AIはいずれ大事」と思っているなら遅い。SEの仕事は、もう前提から変わり始めている
この記事の要約
1年前は「生成AIを学ぶべきか」がテーマだった
でも今は、生成AIを前提に仕事をどう組み替えるかの段階に入っている
変化は1年単位ではなく、数か月で前提が崩れる速度で進み始めている
AIエージェント、MCP、AIのためのインターフェース、x402のような機械決済、Mythosのような高性能モデルの登場は、単なる便利機能ではなく、ソフトウェアの作り方、売り方、使い方そのものを変え始めている
これから強いSEは、コードを書く人ではなく、AIに何を任せ、人がどこを握るかを設計できる人だ
1年前、私は生成AIについて記事を書いた。
今読み返すと、正直かなり甘い。
間違っていたわけではない。
ただ、進化の速度を見誤っていた。
あの頃は、生成AIは「これから重要になる技術」として語れた。
でも今は、もうそんな段階じゃない。
生成AIは、これから重要になるものではない。
もうすでに、仕事の前提を壊し始めているものだ。
そしてたぶん、ここから先はさらに速い。
1年後にまた読み返したら、今のこの文章すら保守的に見える気がしている。
もし今もまだ
「生成AIはいずれ大事になる」
くらいの感覚でいるなら、少し危機感を持ったほうがいい。
問題は、AIが便利かどうかではない。
問題は、AIがいる前提で、自分の仕事の価値がどう変わるかだ。
生成AIの本当の変化は、回答精度ではなく“仕事の単位”が変わったこと
多くの人は、AIの進化を次のように見ていると思う。
文章がうまくなった
コード補完が賢くなった
調べ物が速くなった
要約の精度が上がった
もちろんそれも事実だ。
でも、現場で効いてくる変化はそこではない。
本当に大きいのは、AIに渡せる仕事の単位が変わったことだ。
少し前までは、こんな使い方が中心だった。
文章の下書き
メール案の作成
関数の雛形
SQLのたたき台
エラー文の解説
でも今は違う。
調査して方針をまとめる
コードや設計書をまたいで影響範囲を洗う
複数の仮説を出して切り分け順を考える
会議内容を整理して課題を抽出する
顧客の業界課題まで踏まえて提案のたたき台を考える
こういう連続した仕事にまで、AIが入り込んできている。
これはかなり大きい。
なぜなら、仕事の価値基準が
「自分で全部できるか」
から
「AIと人間の境界線を設計できるか」
に変わるからだ。
ここをまだ「便利ツールが増えた」くらいで見ていると、危ないと思う。
AIエージェントが普及すると、SEの仕事は“実装”より“委譲設計”が重くなる
最近はAIエージェントという言葉をよく聞く。
ただ、この言葉は流行語っぽく消費されやすい。
でも本質はもっと地味で、もっと大きい。
本質は、モデルにどこまで権限と文脈と手段を与えるかだ。
単発で質問して答えをもらうだけなら、従来の生成AIの延長で理解できる。
でもエージェントは違う。
調べる
仮説を立てる
ツールを使う
次の行動を決める
必要なら再試行する
状態を引き継ぎながら進める
こうした流れの中にAIが入ってくる。
ここで必要になるのは、単なる実装力ではない。
これからのSEには、少なくとも次の4つが必要になると思っている。
1. タスク分解力
AIに「これやって」で通る仕事は限られている。
何を入力にして、何を出力にして、どこで成功と判断し、どこで止めるのか。
この単位を切れないと、AIは使いこなせない。
2. ツール設計力
AIはツールを使えるほど強くなる。
でも逆に、ツールの入出力が曖昧だと一気に壊れる。
人間向けの
「だいたい分かるでしょ」
は、AIには通用しない。
3. 文脈制御力
AIは長い文脈を扱えるようになってきた。
でも無限ではない。
余計な説明、余計な資料、余計なツールが増えるほど、精度は落ちやすい。
何を見せるか、何を見せないか。
ここも設計になる。
4. 監査と責任の感覚
AIが仕事を進めるほど、
「誰が最後に責任を持つのか」
が重要になる。
ここを曖昧にしたまま導入だけ進めると、たぶんそのうち事故る。
つまり、SEの価値は
自分で全部作ることではなく、
AIにどこまで任せ、人がどこを握るかを設計すること
へ移っていく。
私はもう、生成AIを“試している”段階ではない
ここまで少し大きな話を書いてきたけれど、これは机上の空論ではない。
私自身、仕事の中で生成AIの入り方がこの1年でかなり変わったと感じている。
私は仕事でシステム保守を請け負っている。
システムエラーが発生したとき、以前ならログを追い、設計書を見返し、関係する処理を順番に洗って、原因候補を絞っていく流れが基本だった。
もちろん今でも最終判断は人間がやる。
ただ、その初動のスピードと、調査の進め方は明らかに変わった。
もちろん、顧客情報・個人情報・機密情報を含む資料を、そのまま外部AIに渡すことはしない。
ただ、社内ルールの範囲で、固有名詞や機密情報を外したうえで、エラー内容や処理の流れを抽象化すると、GeminiやNotebookLMで次のような仮説出しをかなり早い段階で回せるようになった。
どの機能や処理が怪しいか
どの設計上の前提とぶつかっていそうか
どういう切り分けを先にやるべきか
対応策として何が考えられるか
さらに有効だと感じているのは、ログが足りないときの次の打ち手まで相談できることだ。
たとえば、いま出ているログだけでは原因の切り分けが難しいときに、次のような観点を整理してもらっている。
どの処理の前後で追加ログを取るべきか
DBのどこを見ればよさそうか
どのテーブルの状態や更新履歴を確認すべきか
これは単に「調べてもらう」使い方ではない。
次にもっと調べやすくするための観測設計に近い。
保守業務では、初動で論点を外すと時間が溶ける。
しかも、そもそも十分なログが取れていないことも珍しくない。
だから、ログと設計書をまたいで見ながら、
何が足りないのか
次にどんな情報を取れば前に進めるのか
を整理できるのはかなり大きい。
私はここに、生成AIの本質的な価値を感じている。
正解を出してくれることではない。
調査の論点を早く並べ、次に見るべき情報を具体化してくれることだ。
営業同行の場面でも同じだ。
事前にGeminiで、公開情報をもとに顧客企業の取り組みや業界課題、最近の流れを整理する。
そのうえで、次のような観点から質問を組み立てている。
何を聞くべきか
どんな論点を持ち込むべきか
どこに潜在的な課題がありそうか
これはかなり大きい。
なぜなら、営業の場では顧客が最初から課題をきれいに言語化してくれるとは限らないからだ。
むしろ実際には、表に出ている相談の奥に、別の課題が隠れていることが多い。
本当は運用負荷が高い
実は属人化が進んでいる
将来の拡張に不安がある
データ連携や権限制御に見えない問題がある
こうした潜在課題にアプローチするには、その場で思いつきの質問をするだけでは足りない。
顧客の文脈と業界の文脈を踏まえて、仮説を持って聞く必要がある。
私はそこで生成AIを使っている。
打ち合わせ後には、議事録をそのまま使うのではなく、機密情報や固有名詞を外したメモをもとに、課題を整理している。
そのうえで、Geminiを使って
「本当の課題はどこにありそうか」
「次にどんな提案ができるか」
を検討する。
さらに、ヒアリング内容をイメージ化して顧客に共有し、こちらの理解と相手の思いが合っているかも確認している。
ここでも感じるのは、生成AIの価値は単なる効率化ではないということだ。
調査
質問
課題整理
提案
認識合わせ
この流れそのものを、以前より速く、深く、具体的にできるようになっている。
こうして振り返ると、生成AIは私の仕事の一部を置き換えたのではない。
調査の始め方、会話の整理の仕方、提案の組み立て方、顧客との認識の合わせ方を変え始めている。
だから私は、次の1年で変わるのは作業速度ではなく、
仕事の設計そのものだと思っている。
これからは“AIのためのインターフェース”を作れる人が強い
ここは今後かなり重要になる論点だと思っている。
これまでのソフトウェアは、基本的に人間が使うことを前提に作られてきた。
ボタンが押しやすいか
フォームが分かりやすいか
エラーメッセージが親切か
画面遷移が自然か
もちろん今でも大事だ。
でも、AIエージェントが本格的にソフトウェアを使うようになると、別の問いが生まれる。
そのシステムは、AIにとって使いやすいか。
これがAIのためのインターフェースの話だ。
AIにとって使いやすいインターフェースには、たとえばこんな特徴がある。
入出力が構造化されている
ツール名と役割が曖昧でない
認可範囲が明確
エラーの意味が機械的に判別できる
冪等性や再実行条件が定義されている
実行前確認や承認ポイントが切り出されている
人間向けには分かりやすいけれど、AIには曖昧すぎる設計は意外と多い。
これからは、人が見やすい画面だけではなく、
AIが安全に呼べる境界面も価値になる。
たぶん近い将来、API設計がうまい人と同じ文脈で、
エージェント向けインターフェース設計がうまい人
が評価されるようになると思う。
UIの時代から、ハーネスの時代へ
この話はさらに先がある。
これまでのソフトウェアは、ユーザー体験の中心にUIがあった。
でもエージェント時代は、その手前に別の層が入る。
それが、ここではざっくりハーネスと呼ばれるものだ。
ハーネスというのは、雑に言えば、AIに対して次のようなものをまとめて与える実行環境や制御層のことだ。
どんなツールを見せるか
どんな制約をかけるか
どういう順番で仕事を進めるか
どこで人間承認を挟むか
どう失敗を検知するか
この層が強くなると、アプリの競争力は単なるUIではなく、
どれだけ安定してAIに仕事をさせられるか
で決まってくる。
つまり今後は、画面を作るだけでは足りない。
AIが働くための作業場そのものを設計できる人が強い。
ここまで来ると、SEの仕事はかなり変わる。
画面、API、DBだけ見ていればよかった時代より、設計対象が一段増えるからだ。
MCPは、AI時代の“接続の標準化”を進めるかもしれない
ここで出てくるのがMCPだ。
難しく聞こえるけれど、ざっくり言えば、AIが外部データやツールやワークフローにつながるための共通ルールのようなものだ。
この考え方が広がると何が起きるか。
AIごと、ツールごとにバラバラだった接続方法が整理される
AIが業務機能を呼びやすい世界に近づいていく
これは地味に見えるけれど、かなり大きい。
なぜなら、接続の考え方が整理されるほど、AIは単なるチャット相手ではなく、
実際に業務の中で動く存在
に近づいていくからだ。
システム設計の視点で見ると、これは
人が操作する画面をどう作るか
だけでなく、
AIが安全に業務機能へ到達する道をどう作るか
が論点になるということでもある。
402コードとx402は、AI時代の“課金の常識”を壊すかもしれない
ここは一見ニッチだけれど、個人的にはかなり面白い論点だと思っている。
HTTPの402 Payment Requiredは、長いあいだ「将来用に予約されたコード」のような存在だった。
知っている人は知っているけれど、一般的な実運用ではそこまで前に出てこなかった。
でも最近は、この空白を埋めるような流れが出てきている。
その1つがx402だ。
ここで面白いのは、単なる決済機能としてではなく、
機械同士がその場で小さく支払う前提
が見えてくることだ。
AIエージェントが本当に働く主体になっていくなら、たとえば次のようなものに対して、その場で細かく支払える仕組みが必要になる。
情報取得
API利用
検索実行
計算資源の利用
コンテンツ閲覧
外部ツールの呼び出し
今のWebは、
アカウント登録
APIキー発行
月額契約
人間向けの請求管理
が前提になっている。
でも、AIエージェントが大量に外部サービスを呼ぶ世界では、この仕組みは重すぎる。
そのたびに人間が契約していたら遅すぎるし、月額課金だけでは粒度が荒い。
ここで、
「使った分だけ、機械がその場で払う」
という思想が現実味を帯びてくる。
もちろん、まだ普及はこれからだと思う。
でもこれは単なる決済の話ではない。
ソフトウェアが人向けの商品から、AI向けの部品にもなる
という変化の入口だと思っている。
“AIが使う前提のAPI”は、SaaSの値付けすら変える
もしAIエージェントが外部ツールを呼び、調査し、比較し、必要に応じて課金まで行うようになるなら、SaaSやAPIの売り方も変わるはずだ。
今の主流は、たとえば次のようなものだと思う。
月額
席数課金
利用量上限付きプラン
エンタープライズ契約
でもエージェント向けの世界では、次のような超細粒度の課金が自然になるかもしれない。
1回の照会
1件の検索
1回の推論
1回の承認要求
1件の意思決定支援
そのとき必要になるのは、次のような設計だ。
機械が理解しやすい価格提示
即時決済
支払い上限
認可ポリシー
ログと監査
不正利用防止
つまり、料金表ですら人間向けの説明だけでは足りなくなる。
AIが判断しやすい価格インターフェース
が必要になる。
この変化を先に見ている企業は強いと思う。
Mythosが示しているのは、“便利”より先に“危険なほど使える”領域が来るということ
最近の話で象徴的だと思うのが、Mythosのように語られる高性能モデルの扱いだ。
ここでは特定の製品紹介というより、能力が高すぎるがゆえに、公開範囲や利用方法に慎重さが求められるAIモデル群の象徴として見ている。
ここで重要なのは、モデル名そのものではない。
重要なのは、
モデル能力の伸びが、社会実装の受け皿を先に壊し始めている
ということだ。
私たちはつい、AIの進化を次のように見積もってしまう。
ちょっと便利になる
業務効率が少し上がる
作業が速くなる
でも、ある領域ではもう、そんな話ではなくなりつつある。
どこまで権限を与えるのか
どこまで自律性を許すのか
誰が監督するのか
防御と悪用の境界をどう引くのか
公開のタイミングをどう判断するのか
こうした制度と設計の問題が、一気に前に出てくる。
つまり今後のSEに必要なのは、新しいツールを触る能力だけではない。
能力が高すぎるAIを、現実のシステムに安全に埋め込む設計感覚
だ。
ここを軽く見ていると危ない。
たぶん、私たちが想像しているより先に、
できるけど、そのままつないではいけないAI
が増えてくる。
40代以降のSEは不利どころか、ここで勝てる可能性がある
こういう話をすると、若い人のほうが有利に見えるかもしれない。
新しいツールに抵抗がないし、試すスピードも速いからだ。
でも、私はむしろ逆の側面があると思っている。
エージェント時代に価値が上がるのは、
どこで壊れるかを先回りして考えられる人
だからだ。
その権限設計で本当にいいか
その再試行は二重実行を起こさないか
そのログで監査証跡は足りるか
その自動化は例外時に誰が止めるのか
その課金は暴走しないか
その接続先は安全か
こういう問いは、現場経験がある人ほど強い。
AI時代に重要なのは、全部を自分で手作業でやることではない。
壊れない枠組みを先に作ること
だ。
そしてそれは、経験者のほうが得意なことが多い。
だから本当に危ないのは、年齢ではない。
危ないのは、
経験があるのに、前提が変わっていることを認めないこと
だと思う。
まだ「とりあえず触っておけばいい」と思っている人へ
少し強く言う。
その段階は、もう長くは続かないと思う。
もちろん、触らないよりは触ったほうがいい。
でも2026年の今必要なのは、「お試し」ではなく、
仕事をどう再配線するかの設計
だ。
これから強くなる人は、次のようなことを考えている。
AIに何を見せるか
AIに何をさせないか
人間の承認をどこで挟むか
失敗したとき誰が止めるか
課金と権限をどう制御するか
監査証跡をどう残すか
逆に、
「便利ですね」
「たしかに速いですね」
で止まっている人は、思っている以上に置いていかれるはずだ。
理由は単純だ。
変化が1年単位ではなく、
運用設計が間に合わない速度
で来るからだ。
私は、次の1年で“ソフトウェアは人間のためだけのものではなくなる”と思っている
これは少し大きく言いすぎに見えるかもしれない。
でも、かなり本気でそう思っている。
これから増えるのは、AIを載せた既存アプリだけじゃない。
エージェントが触ることを前提にしたAPI
AIにとって分かりやすいツール設計
MCPで公開される業務機能
x402のような機械決済前提のマイクロサービス
人間向けUIより、ハーネスやガードレールが競争力になるプロダクト
こういうものが、少しずつ増えていくはずだ。
つまり、これからのソフトウェアは
人が使うもの
であると同時に、
AIが呼ぶもの
になっていく。
この視点を持てるかどうかで、設計の勘所はかなり変わる。
結論
1年前の私は、生成AIを「これから重要になる技術」だと思っていた。
今の私は、もっと強く思っている。
生成AIは、もう周辺技術ではない。
仕事の前提、設計の前提、課金の前提、インターフェースの前提を壊し始めている。
AIエージェントは、単なる便利機能ではない。
MCPは、単なる接続仕様ではない。
x402は、単なる決済ネタではない。
Mythosは、単なる高性能モデルの話ではない。
全部つながっている。
それは、
ソフトウェアが人が操作するものから、人とAIが分担して動かすものへ変わっていく流れ
だ。
そしてたぶん、この変化は今多くの人が思っているより早い。
1年後にまたこの記事を読み返したら、私はまたこう思う気がする。
「2026年の自分も、まだ見積もりが甘かった」
だから、まだ
「生成AIはいずれ大事」
くらいで止まっているなら、少し危機感を持ったほうがいい。
本当に考えるべきなのは、
AIを使うかどうかじゃない。
AIがいる前提で、自分の仕事と、自分の価値と、自分のサービスをどう作り直すか
だ。
そこまで考え始めた人から、次の波に乗れる。
たぶん、もうその段階に入っている。
みなさんの職場では、生成AIはまだ「便利ツール」扱いでしょうか。
それとも、仕事の進め方そのものを変え始めていますか。
私はまだ、この変化をうまく言い切れていない気もしています。
でも少なくとも、もう「そのうち大事になる技術」ではないところまで来ている気がします。
この記事で書いた「AIを使う力」や「設計する力」を深めたい人向けに、相性のいい本とツールを置いておきます。
まず、生成AIを仕事の中でどう使うかを整理したい人には、プロンプトエンジニアリングの入門書が入りやすいです。
次に、AI時代でも結局重要になる設計力を磨きたい人には、アーキテクチャの本がかなり相性がいいです。
営業同行や議事録整理、ヒアリング内容の可視化まで含めて効率化したい人には、AIボイスレコーダー系も相性がいいと思います。
もちろん、会議や商談で録音ツールを使う場合は、社内規定、取引先ルール、相手の同意を守ることが前提です。
専門用語の用語集
AIエージェント
複数ステップの作業を計画し、ツールを呼び出し、状態を保ちながら仕事を進めるAIシステム。単発の質問応答より、自律性と継続性が高い。
タスク分解
大きな仕事を、入力・出力・完了条件が明確な小さな単位に分けること。AI活用ではこの切り方が精度を左右する。
MCP
AIが外部データ、ツール、ワークフローにつながるための共通的な接続の考え方。AI時代の接続標準として注目されている。
AIのためのインターフェース
人間ではなくAIエージェントが安全かつ確実に利用できるよう設計されたAPI、ツール、権限境界、エラー設計などの総称。
ハーネス
AIに対して、ツール、権限、制約、承認フロー、実行環境をまとめて与える制御層。エージェントの実用性と安全性を左右する。
ガードレール
AIやエージェントが危険な挙動や不適切な出力をしないようにするための制約、承認、ポリシー、監査の仕組み。
冪等性
同じ処理を複数回実行しても結果が変わらない性質。再試行が発生しやすい自動化では特に重要。
402 Payment Required
HTTPステータスコードの1つ。長いあいだ「将来用に予約されたコード」として扱われてきた。
x402
HTTP 402の文脈を活かしつつ、機械同士の小額決済や即時支払いを扱う方向で注目されている考え方や実装群。AI時代のマイクロペイメント文脈で語られることが多い。
マイクロペイメント
少額の料金をその都度支払う仕組み。AIエージェントが外部ツールを使う世界では重要性が増す可能性がある。
Mythos
高性能かつ扱いに慎重さが求められるAIモデル群の象徴として、この記事では扱っている。単なる便利さではなく、権限、監査、安全設計、公開範囲の問題を前面に押し出す存在。
潜在課題
顧客自身がまだ明確に言語化できていないが、実際には存在している問題。表面的な相談の奥にあることが多い。
観測設計
問題発生時に原因を追えるよう、どこで何のログや状態を取るかを事前に設計すること。保守性や障害対応速度に直結する。
おわりに
こういうテーマをこれからも、現場目線で掘り下げていきます。
生成AI、システム開発、仕事の進め方の変化について、単なる流行話ではなく、
それで仕事がどう変わるのか
まで言語化していきたいと思っています。
プロフィールはこちら
生成AI活用、記事構成の壁打ち、システム開発まわりの言語化、技術記事の整理などの相談はこちら
