※ この記事にはアフィリエイト広告が含まれることがあります。
AIエージェントを通してシステムを利用する場面は、これから増えていく。 以前から使っている仕組みについて、その前提に合ったAAA（Authentication、Authorization、Accounting）をどう設計するか、ChatGPTに相談していた。
その仕組みは作った当時の用途には十分だったが、AIエージェントが関わることを前提にすると考え直す箇所がある。 今の作りに機能を足すのか、全体の役割分担から見直すのか。 ChatGPTと話しながら、選択肢とそれぞれの問題を整理していた。
仕組みを考え、これなら課題を解決できそうだと確認するところまでは面白い。 けれど方針が決まったあとには、それをコードにして動かす作業が残る。
以前は、その段階まで来ると「あとは手を動かすだけか。面倒だな」と思っていた。 考えたことを書き起こさなければ完成しないが、私にとって一番面白い部分はすでに終わっている。
もちろん、動くものを届けなければ価値にはならないので、そこで止めるわけにはいかない。 そのため、実装からデリバリーまでを滞りなく進める仕組みも設計してきた。
今回も、どう作ればよいかはだいたい整理できた。 いつもなら、ここからが一番面倒に感じるところだった。
その実装も、ChatGPTに頼めばよい。
一番面倒だと思っていた「あとは手を動かすだけ」が、自分の手から離れる。 少なくともこの時点では、それがただうれしかった。
相談の先にある作業も任せられる
私の感覚では、AIがそれまでと比べて圧倒的に進化したのが2026年2月で、7月にはそこからさらに一段進んだ。
今は、AAAについて、どの条件からどのような制限が必要になるのか、何ができれば課題を解決したことになるのかを整理している。 そのうえで、想定する規模や数年後にどうなっているかを考え、解決に使う技術を選ぶ。 複数の技術を組み合わせられるか、その組み合わせに無理がなく、良いやり方と言えるかも判断する。
この判断では、技術から感じる筋の良さも外せない。 普及しなさそうな技術は、理由をすべて説明できなくても、なんとなく分かることがある。
AIには、関連する技術やネット上の議論を調べてもらい、現在どの程度使われているのか、採用事例が増えているのかを確認してもらう。 その結果が自分の感覚と合っているかを見て、違っていれば食い違う理由を調べる。
方針が決まれば、同じ会話のままリポジトリを調べて実装し、テストし、必要ならデプロイし、そこで見つかった不具合も直せる。
2026年8月8日、相談していた最中にXへこう書いた。
どうやろうかなー、と思っていたものを大体どうすれば良いか整理ついた。
あとはやるだけだしもう勝手にできあがんねーかなー、って思ってたところが勝手にできるようになったのスゴイ（語彙
調べたり、今時のトレンドは、みたいなものを調査するのもかわりにやってくれる…
続くポストには、少し前まで自分でやっていた調査を書いた。
自分でネット上のディスカッションを片っ端から読んだり、やらそれっぽい文字を使っているOSSを見まくったり、何が書いてあるかわからん大手のドキュメント読んだりをしなくてよくなったのスゴイ（語彙）
新しい領域を調べるとき、これまでは検索結果を何ページも開き、関連しそうなOSSを探し、公式ドキュメントとネット上の議論を行き来していた。 何を探せばよいのかがまだ分からない段階では、検索に使う言葉を見つけるまでにも時間がかかる。
伝え方が分からなくても相談を始められる
最近、エンジニアではない人にも、やりたいことや困っていることを、とにかくAIに話してみればよいと言っている。
何を頼めばよいか整理できていなくてもよい。 適切な用語を知らず、どう伝えればよいかも分からないことまで含めて話せば、AIと一緒に状況を整理できる。 その先で、必要なソフトウェアを作れる場合もある。
これは先日書いた、パソコンがユーザーの手元に戻ってきたという感覚にもつながっている。 不便を感じた本人と、それを直すソフトウェアのあいだにあった距離は、急速に短くなっている。
自分が面倒だと思っていた実装まで任せられ、エンジニアではない人も自分の不便を直せる場面が増える。 この変化をうれしく思う一方で、自分については別の疑問が出てきた。
私はこれから、何を強みにすればよいのだろう。
面白かったのは部品を組み立てることだったのか
私は、既存のコンポーネントを決められた方法で組み合わせ、その上にアプリケーションを作ることだけを面白いと思ってきたわけではない。
既存の枠組みでは解きにくい問題を見つけ、ここに新しい考え方や薄い仕組みを一枚加えれば解けるのではないかと考える。 その仮説を実装して確かめるところに、エンジニアとしての面白さを感じてきたのだと思う。
そのときに使っているのは、過去に触った製品やAPIの知識だけではない。 新しい問題を見たときに、「これは以前のあの問題と同じ種類ではないか」「今ならこの働きを持つ仕組みがあるはずだ」「この層に一枚かぶせれば解けそうだ」と推測するためにも、過去の経験を使っている。
認証、認可、委任、状態、トランザクション、障害、責任の境界といった問題は、技術の名前や置かれる場所が変わってもなくならない。 新しいパラダイムが現れただけで、経験者と未経験者が完全に同じ地点へ戻るわけではなさそうだ。
それでも安心はできなかった。
過去の経験が使えなくなるとき
Xのスレッドは、三つ目のポストで不安のほうへ進んだ。
AAAってこんなもんだよね、きっと今時はこんな感じのものがあるよね、この領域ではこんな被せ方できるよね、みたいな過去の記憶は役に立っているけれど、何かがシフトすると過去の経験値は役に立たなくなるので一定シフトが増えるその瞬間が既存普通エンジニアが不要になるタイミングかな？
技術の前提が大きく変われば、過去に身につけた組み立て方が使えなくなることはある。 AIによってその変化が速くなり、大きな転換が続くのであれば、長く実装してきた経験はどこまで優位性になるのだろう。
相談を続けていて、経験が役に立たなくなるのは、技術の名前が変わったときではなく、過去に理解した問題を新しい世界に対応づけられなくなったときではないかと考えた。
「昔はこうだったから、今もこうだろう」で止まれば、経験は判断を誤らせる。 昔はどの制約のためにその設計を選んだのか、その制約はまだあるのか、新しく増えた制約は何かを考え直せるなら、過去の経験は新しい技術を理解するために使える。
私の強みが残るかどうかは、経験の年数よりも、この考え直しを続けられるかにかかっていそうだ。
実装から離れると失うもの
一番面倒だった実装を任せられるのは、今も喜ばしいと思っている。 しかし、自分で手を動かさなくなれば、新しい技術に実際に触れることで得てきたものまで失うのではないか。
これまでの失敗や設計、障害、組織上の制約から得た知識は、実装から離れてもすぐには消えない。 一方で、新しい技術を実際に動かし、予想と違う挙動を見て理解を修正する経験は、触らなければ増えない。
前者を蓄積による設計力とするなら、後者は設計の前提を更新する力である。 技術の変化が速くなるほど、後者を止めたときの影響は大きくなる。
ただ、更新を続けるために、すべてのコードを自分で書く必要はなくなった。 設計上の仮説を立て、AIに実装してもらい、実際に動かし、境界条件や失敗を確認する。 予想と違えば設計を直し、もう一度動かす。
自分が何行書いたかではなく、仮説を実装によって確かめ、自分の理解を修正したかどうかで考えればよいのかもしれない。
2026年8月に残しておく答え
AIが代わりやすいのは、既知の部品を既知の方法で組み立てることそのものを価値としてきた仕事なのだと思う。
既存の枠組みで足りないものを見つけ、どこへ何を加えれば解けるかを考える。 新しい技術を以前の問題と対応づけながら、違っている部分を見つける。 そして、考えたことを実際に動かして確かめる。
少なくとも2026年8月のお盆直前には、そこに自分の強みが残るのではないかと考えている。
その実装をAIに任せることは、実装から離れることと同じではない。 動いたものを見て自分の予想を確かめ、外れた理由を考えられるところに居続けるなら、自分の中にある設計の前提も更新できる。
この考えが合っているかは、近い将来に分かるかもしれない。 変化の途中にいるあいだは、答え合わせができないままかもしれない。