この記事は、これまで自分が書いてきたAI活用・AIエージェント・エンジニアの役割に関する記事を、自分なりの流れで並べたインデックスです。
最初から連載として設計していたわけではありません。
そのときどきに、自分がAIを使いながら感じた違和感や変化を、少しずつ言葉にしてきたものです。
一部、これから書く予定の記事も含めています。
リンクは後から差し替える前提で、記事の流れと位置づけを整理しています。
はじめに
ここ最近、AIエージェントや生成AIを使いながら開発する中で、自分の中の仕事の見え方が少しずつ変わってきました。
最初は、AIをどう使うか、AIの出力をどう見るか、という話だったと思います。
でも考えていくうちに、話は少しずつ広がっていきました。
AIエージェントは、プログラミングの歴史の中でどう見ればいいのか。
コードを書かない、コードを見ない開発は、何を変えるのか。
人間がコードを所有し、すべて理解するという前提は、これからも同じなのか。
AIの出力を評価できるとはどういうことなのか。
エンジニアにとっての「正しさ」は何で決まるのか。
自分の判断基準をAIに読ませるにはどうすればいいのか。
AIに任せる仕組みをどう設計するのか。
設計書やドキュメントは、AI時代に何のために残すものなのか。
AIで実装が速くなっても、仕事全体はなぜ速くならないのか。
コードを読まない・書かない人を、エンジニアとしてどう見るのか。
そして、AIを使った創作や、これからエンジニアになる人のことをどう考えるのか。
この記事は、それらの記事を自分なりの流れで並べたインデックスです。
単なる記事一覧というより、AIを使うようになって、自分の中のエンジニア観・仕事観・創作観がどう変わってきたのか を整理するためのページとして書いています。
目次
この記事では、AIを使うようになって変わってきた自分の考えを、だいたい次の流れで並べています。
| 章 | テーマ | 含めている話 |
|---|---|---|
| 第1部 | AIエージェントで、開発の手触りが変わる | コードを書く、読む、所有する感覚の変化 |
| 第2部 | では、人間は何を見るのか | AIの出力をどう評価するか、自分の判断基準をどう持つか |
| 第3部 | AIに任せるための仕組み | 任せる単位、制約、ドキュメント、合意、検証の話 |
| 第4部 | 現場とエンジニア像の変化 | 実装速度、現場制約、コードを読まない・書かない開発 |
| 第5部 | これから学ぶ人、作る人への視点 | AIを使った創作、新人エンジニアが大切にしていいこと |
最初はプログラミングの中だけの話に見えていました。
でも、だんだんと「AIをどう使うか」だけではなく、人間が何を見て、何を判断し、どこに責任を持つのか という話になってきたように感じています。
第1部：AIエージェントで、開発の手触りが変わる
このまとまりでは、AIエージェントによって、自分の中の「プログラミングしている感覚」がどう変わったのかを整理しています。
コードを書くこと。
コードを読むこと。
コードを自分の管理下に置くこと。
これまで当たり前に思っていた前提が、少しずつ変わってきた感覚があります。
【AIエージェント時代の開発①】アセンブラからAIエージェントへ：私が「書かなくなった」30年と、その先にあるもの
AIエージェントによる開発の変化を、突然の断絶ではなく、アセンブラから高級言語、フレームワーク、検索とコピペへ続いてきた抽象化の流れの先にあるものとして整理した話です。
AIエージェントは、単にコード生成が速いツールというだけではなく、人間がより大きな問題に向き合うための抽象化の一段先にあるのかもしれません。
自分にとっては、AIによる変化は突然やってきたものというより、長く続いてきた「書く場所が変わる」流れの中にあるようにも見えています。
【AIエージェント時代の開発②】「書かない」から「見ない」へ：AIエージェント時代に変わるエンジニアの仕事
AIエージェントを使うことで、コードを書くことだけでなく、コードを細かく読むことも減ってきた、という話です。
最初は、AIが書いたコードをどうレビューするかが問題だと思っていました。
でも実際には、AIに作らせて、動かして、期待と違う部分を指摘し、また直すというサイクルが中心になってきました。
コードを読むことそのものよりも、動く成果物を見て、期待に近づけていくことの比重が上がっているように感じています。
【AIエージェント時代の開発③】プログラムは、もう人間だけのものではなくなってきた
AIエージェントがコードを書くようになると、プログラムは人間が完全に書き、読み、管理するものではなくなっていくのではないか、という話です。
これまでのコードレビューは、バグを見つけるだけではなく、プログラムを人間の理解できる範囲に置いておくための文化でもあったのかもしれません。
でもAIが大量にコードを書き、人間がすべてを読むことが現実的ではなくなると、レビューの中心も少し変わってきます。
コードの細部を管理するより、成果物の振る舞いを観察し、リスクを見つけ、必要な制約をAIに返していく。
人間はコードの所有者というより、成果物を観察し、検証し、方向づける存在になっていくのかもしれない、という話です。
第2部：では、人間は何を見るのか
AIがコードを書き、AIの出力をそのまま使う場面が増えるほど、人間側の見る力が問われるようになります。
ここでは、AIの出力をどう評価するのか、エンジニアの正しさとは何なのか、自分の判断基準をどう残すのかを整理しています。
AIの出力をそのまま使える人は、何を見ているのか
AIを信じるかどうかではなく、自分がその出力を評価できるかどうか、という出発点の話です。
AIの出力をそのまま使うことと、何も見ていないことは違う。
プログラミングでは、テストや動作確認があります。
エラーが出れば気づけますし、仕様と違えば直せます。
一方で、文章や画像、設計方針のような「正解がはっきりしない成果物」では、何をもって良いとするのかが難しくなります。
そこで必要になるのは、AIを信じることではなく、自分が何を見て判断するのか なのだと思いました。
エンジニアの「正しさ」は、流行と経験と好みでできている
技術的な正しさは、絶対的なものではなく、流行・経験・現場・好みの中で変わっていくものなのかもしれない、という話です。
エンジニアはよく「正しい設計」「良いコード」「あるべき構成」について話します。
でも、その正しさは、いつも完全に客観的なものとは限りません。
流行しているアーキテクチャ。
過去に痛い目を見た経験。
今いる現場の制約。
自分が読みやすいと感じる好み。
そういうものが混ざって、技術的な判断は作られているのだと思います。
AI時代になると、レビューや設計判断にもAIが入ってきます。
そのとき、人間が持っていた「正しさ」も、改めて見直す必要があるのではないかと感じました。
AIに読ませる自分ルールは、正解集ではなく更新履歴なのかも
AIに自分の考え方を読ませるために、判断基準や文章の書き方をルール化しようとした話です。
最初は、自分の考え方を my-thinking-rules.md や my-writing-rules.md のような形でまとめれば、AIの出力が安定するのではないかと考えていました。
でも、やってみると簡単ではありませんでした。
エンジニアの判断基準は、技術の流行、現場の制約、自分の経験、AIツールの進化によって変わっていきます。
そのため、固定された正解集としてルールを作ろうとしても、すぐに古くなってしまう。
それなら、AIに読ませる自分ルールは、絶対的な正解集ではなく、その時点の自分の考え方を残しておく更新履歴 として扱う方が自然なのかもしれない。
この記事は、AI時代に自分の文脈や判断基準をどう残していくか、という話です。
第3部：AIに任せるための仕組み
AIに任せるには、ただ指示するだけでは足りない気がしています。
任せる単位。
前提。
制約。
合意。
ドキュメント。
テストやハーネス。
AIが安全に働けるように、人間がどんな仕組みを用意するのかを考えるまとまりです。
AIエージェント時代、プログラマーは「任せる仕組み」を設計する人になるのかも
AIエージェント時代のプログラマーは、単に「書く人」から「任せて確認する人」になるだけではないのかもしれません。
最初は、自分も「これからはAIに任せて、人間が確認する仕事になっていくのかな」と考えていました。
でも、それだけだと少し浅い気がしてきました。
AIに任せる単位を作る。
前提を整える。
権限を決める。
検証を組み込む。
必要なところで人間が止められるようにする。
複数のAIエージェントに役割を分ける。
そう考えると、人間の役割は単なる監視役ではなく、AIエージェントが安全に働ける仕組みを設計する人 に近づいていくのかもしれません。
AI時代の設計書は、コードから分からない「合意や意図」を残すだけでいいのでは？
AIで実装後のコードから設計資料を逆生成できるなら、従来の詳細設計書をすべて先に作る必要は薄くなるのかもしれない、という話です。
設計書には、少なくとも2つの役割があると思っています。
1つは、関係者と認識を合わせるための 合意用の設計書。
もう1つは、実装後にシステムの構造を把握するための 理解用の設計書 です。
AIがコードを読んで、構成やデータの流れ、画面やモジュールの関係を整理できるようになると、理解用の資料はコードから逆生成しやすくなります。
一方で、コードだけでは「なぜそう決めたのか」「何をスコープ外にしたのか」「誰と確認したのか」は残りにくいです。
だから、AI時代の設計書は、実装の細部をすべて先に書くものではなく、合意の履歴を残すものとして見直せるのではないか、という話です。
AI時代のドキュメントは、AIに前提を渡すためのコンテキストになるのかも
AIエージェントに開発を任せるには、コードだけでなく、仕様、制約、判断理由、実行手順、テストなどの前提が必要になるのではないか、という話です。
AIはコードを読むことはできます。
でも、コードだけでは分からないものがあります。
- なぜこの設計にしたのか
- どこを変更してはいけないのか
- どの仕様は顧客合意済みなのか
- どの処理は暫定対応なのか
- 何を確認すれば完了なのか
- どのコマンドでテストやビルドを行うのか
こういう情報がないと、AIは毎回推測で動くことになります。
そのため、AI時代のドキュメントは、人間に説明するためだけのものではなく、AIに作業前提を渡すためのコンテキストにもなっていく気がしています。
また、AIに任せるなら、結果を確認する仕組みも必要です。
テスト、Lint、型チェック、ビルド、E2Eテスト、スクリーンショット比較、API疎通確認、確認手順。
こうしたものは、AIが変更した結果を確認するための ハーネス として重要になるはずです。
AI時代、ドキュメントは成果物ではなく開発環境の一部になるのかも
AI時代のドキュメントは、一度作って終わりの成果物ではなく、AIと人間が共有する開発環境の一部になるのではないか、という話です。
これまで設計書やドキュメントは、人間が読むためのものとして考えられることが多かったと思います。
人間が設計書を書く。
人間が設計書を読む。
人間がコードを書く。
コードが変わる。
設計書が古くなる。
こういう流れが、よくありました。
でもAI時代には、設計書やドキュメントをAIが読むようになります。
AIが設計書を読んでコードを書く。
AIがコードを読んで設計資料を逆生成する。
人間がそれを確認する。
確認した内容をドキュメントに戻す。
そして、そのドキュメントをAIがまた次の作業で読む。
つまり、設計書からコードへ、コードから設計書へ、そしてまた設計書からコードへ というサイクルが発生していくのかもしれません。
ドキュメントは納品物ではなく、AIと人間が一緒に開発を続けるための環境の一部として育てていくものになるのではないか、という話です。
第4部：現場とエンジニア像の変化
AIを使うと、個人の実装速度はかなり上がります。
ただ、それだけで現場全体が速くなるとは限りません。
現場の制約、コードを見せられない問題、エンジニア像の変化。
ここでは、AIを使うことで見えてきた現実側のズレを整理しています。
実装は速くなった...でも仕事は？...速くなってないかも
AIエージェントによって、個人の実装速度はかなり上がってきました。
実装してもらう。
テストしてもらう。
エラーを直してもらう。
変更内容を整理してもらう。
自分の手元では、明らかに速くなっている感覚があります。
ただ、仕事全体を見ると、必ずしも同じように速くなっているとは限りません。
仕様確認待ち。
レビュー待ち。
承認待ち。
作業範囲の判断待ち。
次の指示待ち。
AIで実装が速くなったことで、むしろ仕事の流れのボトルネックが見えやすくなった気がします。
個人の実装速度が上がることと、現場全体の開発速度が上がることは同じではない。
この話は、AI活用を個人のスキルだけで考えない方がいい、という感覚につながっています。
AIは使える。でも、現場で一番見てほしいコードは見せられない
AIに慣れたあとで、顧客コードや既存システムをAIに見せられない現場に入ると、開発体験はかなり変わります。
AIは使える。
でも、一番見てほしいコードは見せられない。
このもどかしさを通じて、自分の開発スタイルがすでにAI前提に変わっていたことに気づきました。
AIがあると、既存コードの構造を整理してもらえます。
処理の流れを見てもらえます。
影響範囲の見当をつけてもらえます。
エラー原因の候補を出してもらえます。
でも、セキュリティや契約、機密保持の都合で、コードをAIに見せられない現場はまだまだあります。
このとき重要になるのは、AIを使えるかどうかだけではなく、AIに何を見せられるか なのだと思いました。
「読まない・書かない」プログラミングも増えていくんだろうな...
コードを一行ずつ読んだり書いたりしなくても、AIを使って価値を生み出す人が増えていくのではないか、という話です。
もちろん、責任を持たなくてよいという意味ではありません。
基礎が不要になるわけでもありません。
コードを読めること、書けること、仕組みを理解できることは、AI時代でも大事だと思っています。
ただ、価値を生み出す入口が、コードを書くことだけではなくなってきているようにも感じます。
AIを使って、自分の作りたいものを形にする。
苦手な技術領域をAIに補ってもらう。
動くものを作りながら学ぶ。
そういう人たちを、エンジニアとしてどう見るのか。
自分は、そこを否定するのではなく、リスペクトをもって見たいと考えています。
第5部：これから学ぶ人、作る人への視点
最後は、AI時代に何を大切にしていいのか、少し広い視点で考えた記事です。
開発から少し外に広がりますが、自分の中ではつながっています。
AIを使ったものをどう見るのか。
これからエンジニアになる人は、何を大切にしていいのか。
そういう話です。
「AIが作ったか」より「AIを使って何を作ったか」を見たい
プログラミングの世界では、AIを使うことがかなり自然になってきています。
一方で、文章・画像・音楽・映像のような創作物では、AIを使ったというだけで評価が下がることがあります。
でも実際には、AIを使っていても、人間の意図、選別、修正、判断、手間があります。
AIが出力したものでも、何を選び、何を捨て、どこまで自分のものとして引き受けたのかで、意味は変わると思っています。
もちろん、すでに強く認識されている作風やブランドに寄せすぎる使い方や、こだわりのない量産には違和感があります。
でも、AIを使ったというだけで全部を軽く見るのも違う気がしています。
だから自分は、「AIが作ったか」だけではなく、AIを使って何を作ったか を見たいと思っています。
AIエージェント時代でも、新人エンジニアが大切にしていいこと
AIエージェント時代でも、きれいな出力や正解っぽい形だけではなく、自分の言葉、相手への向き合い方、最後のひと押しのような人間らしさを大切にしていいのではないか、という新人エンジニア向けの話です。
AIを使えば、整ったコードや資料は作りやすくなります。
でも、仕事として見ると、相手が見ているのは資料の完成度だけではないこともあります。
この人は困りごとを理解してくれているのか。
最後まで一緒に考えてくれそうか。
面倒なところから逃げずに向き合ってくれそうか。
自分の言葉で説明してくれているか。
AI時代でも、そういう部分は残る気がしています。
これからエンジニアになる人に向けて、AIを怖がりすぎず使いながらも、自分の言葉や向き合い方を捨てなくていいのではないか、という話です。
おわりに
これらの記事は、最初から連載として設計したものではありません。
そのときどきに、自分がAIを使いながら感じた違和感や変化を、少しずつ言葉にしてきたものです。
ただ、並べてみると、共通しているテーマがあるように感じます。
AIを使うかどうかではなく、AIの出力をどう見るのか。
AIに何を任せるのか。
AIに何を読ませるのか。
AIに何を前提として渡すのか。
どこを人間が判断するのか。
仕事の流れや、エンジニアの役割はどう変わるのか。
AIを使って作られたものを、どう受け止めるのか。
AIによって変わるのは、単に開発ツールだけではないのかもしれません。
自分の仕事の見え方、正しさの置き方、人間が担う役割、そしてものを作ることへの向き合い方も、少しずつ変わってきている気がしています。
まだ答えが出ているわけではありません。
ただ、今の自分には、そんなふうに見えています。