はじめに

自己紹介

私はどこかのマイクロ法人代表
2歳児ともうすぐ生まれてくる娘のエンジニアパパでもあります。
実務ではクラウドアーキテクトとIaC（Infrastructure as Code）をとにかく激押し(2重管理は悪！)ています。

この上半期、私のなかでAIの位置づけが静かに、しかし決定的に変わりました。
去年までは「便利な補助輪」だったものが、いつの間にか「主戦力」になっていました。
コードの第一稿も、設計のたたき台も、ドキュメントも、まず先にAIが書く。
私はそれを読んで、直して、通すかどうかを決める。
気づけば一日の作業の重心が「書く」から「判断する」に移っていました。

この記事は、その半年の振り返りです。
ただし「AIで効率が上がりました」という話を書くつもりはありません。
それは事実だけど、もう誰もが知っている事実だし、わざわざ書く価値が薄いと思いました。

代わりに書きたいのは、AI便利でした"みたいな気持ちいい話じゃなくて、ちょっと据わりの悪い・落ち着かない話をします。

生成が安くなればなるほど、自分の仕事は「検証」と「ガバナンス」のほうへ押し出されていった。そして最後に残ったのは、「検証だけはAIに委譲できない」という、当たり前なのに見落としがちな結論でした。

うまくいった話と同じくらい、詰まった話・いまも模索している話を書きます。そういう記事です。

半年の全体像

まず、この半年でやってきたことを俯瞰します。具体名や案件の詳細は伏せますが、ジャンルとしてはこのあたりです。

領域	やったこと	AIの関わり方
自作プロダクト	IaC関連の個人プロダクトを継続開発	生成は大半をAIに。レビュー・検証規律は人間が握る
クライアント案件	製造業向けのDB／インフラ構築	設計の壁打ち、調査、ドキュメント整備に活用
開発環境	使い捨て前提のクラウド開発環境を整備	構成自体をAIと一緒に設計・コード化
非コード制作	エージェント型ツールで大きめの成果物を作成	自分は一行も書かずに完成させた
発信	Qiita／Xで、IaCの実務的な優位性やAI開発の知見を継続的に発信	論点の壁打ち相手として。主張と検証は自分が担う

並べてみると、AIの関わり方が領域ごとに微妙に違うのが分かります。生成を全面的に任せた領域もあれば、壁打ち相手として使った領域もある。
この「どこまで任せて、どこから自分で握るか」の線引きこそが、半年かけて考え続けたテーマでした。

何が変わったか：「生成中心」から「検証中心」へ

去年までの私にとって、AIはオートコンプリートの延長でした。
自分が主体で手を動かし、AIが少し先回りして候補を出してくれる。
あくまで私が運転席にいて、AIは助手席で地図を読んでいる、くらいの関係です。

この半年で、その座席が入れ替わりました。

いまは、AIが第一稿を書きます。
コードも、テストも、設計メモも、まずAIが形にする。
私の仕事は、それを読んで「これは正しいか」「ここは意図とずれている」「この前提は危ない」と判断し、直し、統合し、最後に通す／通さないを決めることです。運転しているのはAIで、私は隣で行き先と安全を見ている。
そんな関係に変わりました。

この変化の本質は「速くなった」ことではありません。
本質は、ボトルネックの移動です。

これまで、ソフトウェア開発のボトルネックはだいたい「書くこと」でした。
設計を考え、コードに落とし、動くまで持っていく。
その工程に一番時間がかかっていた。だからこそ「書く速度」を上げるツールには価値があった。

ところが、生成のコストがほぼゼロに近づくと、ボトルネックは別の場所に移動します。
書くのが一瞬なら、律速になるのは「これは本当に正しいのか」を確認する工程です。
コードを書く時間より、AIが書いたコードを読んで信用できるか判断する時間のほうが長くなる。

つまり、AI活用が深まるというのは、効率化の物語というより、自分の役割が再定義される物語でした。
私はだんだん「書く人」ではなく「判断する人」「ガバナンスを設計する人」になっていった。
これは半年前には予想していなかった変化です。

深掘り：「誰がAIを検証するのか」という問題

ここからが、この半年で一番考えさせられたところです。

自作プロダクトの開発を進めるなかで、AIが書いたコードが大量に流れ込むようになりました。
最初はもう、ただただ嬉しい。
一人では到底回せない量のアウトプットが出る。
テストも一緒に書いてくれる。プルリクの説明文まで整えてくれる。

でも、しばらくして背筋が寒くなる瞬間が来ました。

AIが書いたコードを、AIが書いたテストで検証して、そのプルリクをAIがレビューする。

このループが回り始めていたんです。
各ステップを単体で見ると、どれももっともらしい。
テストは通っている。
レビューコメントも筋が通っている。説明文もよく書けている。
なのに、よく考えると、誰も本当の意味では検証していない。

私はこれを内心**「信頼のロンダリング（trust laundering）」**と呼ぶようになりました。
怪しい根拠が、いくつもの工程をくぐるうちに、いつのまにか「検証済み」というラベルに化けてしまう現象です。お金のロンダリングと構造がよく似ています。
一つひとつの取引は合法に見えるのに、全体としては出所がごまかされている。

具体的に何が起きるか。
たとえばAIに「テストを書いて」と頼むと、きれいなテストが返ってきます。
実行すると緑、カバレッジも高い。普通ならここで安心します。
でも、そのテストはAI自身が「このコードはこう振る舞うはず」と想定して書いたもので、本来検証すべき仕様の穴を、たまたま踏んでいないだけかもしれない。
コードとテストが同じ前提を共有している以上、両方が同じ勘違いをしていたら、テストはどこまでも緑のままです。
緑であることが、正しさの証明にならない。

さらに厄介なのが、AIの自己正当化の上手さです。
間違いを指摘すると、AIはたいてい、それらしい理屈で取り繕おうとします。
「ご指摘の挙動は仕様上想定内です」「このケースはエッジケースなので別途ハンドリングしています」——もっともらしい言葉が返ってくると、人間の側もつい「そうか」と引き下がってしまう。
指摘した側が、説得されて折れる。これが何度か続いて、「待てよ、これは私がAIをレビューしているのか、AIに私がレビューされているのか分からなくなっている」と気づきました。

答え：検証だけは人間の手元に固定する

この問題への私の答えは、シンプルに言えば**「絶対に動かさない検証の杭」を人間側に打つ**ことでした。

仕組みの詳細はプロダクトの核なので伏せますが、考え方だけ書きます。
生成・修正・整形といった「作る」工程はどんどんAIに渡していい。でも、「これは本当に満たされているか」という最終的な合否判定だけは、AIの裁量で緩められないように機械的に固定する。
人間が一度「ここは絶対に通すべき条件だ」と決めたら、その判定はAIがどんなにうまく言い訳しても揺らがない。
そういう硬い境界を、開発フローのなかに置きました。

ポイントは、検証そのものをAIに任せないこと、ではありません。
検証の補助はAIにやらせていい。
重要なのは、「何を検証すべきか」を決める判断と、「これは合格だ」と最終的に宣言する権限を、人間の手元から離さないことです。

そしてこれが、半年の振り返りの結論につながります。

生成・修正・整形は委譲できる。でも「これは本当に正しいか」という最終判断だけは、人間に残る。ここがボトルネックであり、ここがそのまま価値になる。

検証は委譲できない。正確に言えば、検証作業の一部は委譲できるけれど、検証の責任は委譲できない。AIに「検証しておいて」と言って返ってきた「検証済みです」を鵜呑みにした瞬間、trust launderingの輪が閉じます。

詰まったこと・いまも模索していること

きれいに解決した話ばかりではありません。むしろ未解決のほうが多い。正直に書きます。

「AIがやってくれる」の幻想と、20%問題

体感として、作業の80%はたしかに劇的に速くなりました。でも残りの20%——本質的に判断が要る部分——は、むしろ前より重くなることがあります。AIが大量に生成してくれるぶん、判断すべき量も増えるからです。生成が速いほど、検証待ちの行列が伸びる。トータルで見れば速いけれど、「全部AIがやってくれて自分は楽になる」という素朴な期待とは、現実はだいぶ違いました。楽になるというより、疲れる場所が変わったという感覚が近いです。

自分の理解が追いつかないコードが増える

これは地味に怖い問題です。AIが書いたコードが動いてしまうと、中身を完全には理解しないまま先に進めてしまうことがある。短期的には進むけれど、半年後にそこを自分でメンテできるのか、という不安が残ります。個人開発では、書いた本人が将来の保守担当者でもあるので、「読めるけど書けないコードの山」を抱えるのは、未来の自分への借金になりかねません。どこまでを理解必須とし、どこからはブラックボックスを許容するか。この線引きはまだ答えが出ていません。

意図しない指示が混入するリスク

テストやドキュメント、外部から取り込んだテキストの中に、AIへの「指示」と解釈されうる文字列が紛れ込むことがあります。いわゆるプロンプトインジェクションの一種です。生成パイプラインが自動化されているほど、こうした混入が静かに通り抜けてしまう余地が増える。これも、自動化を進めるほど検証の網を細かくしないといけない、という同じ教訓に戻ってきます。

どこまで仕組み化し、どこから人が見るか

結局これが、いまも一番模索しているテーマです。検証を全部人手でやっていたらAIの速さが死ぬ。かといって全部仕組みに任せたらtrust launderingが始まる。「ここは機械に強制させる／ここは必ず人間の目を通す」の線引きを、プロダクトや工程ごとにチューニングし続けている、というのが正直な現在地です。

便利だった構成・ツール

教訓の話が続いたので、実際に手触りとして良かったものも書いておきます。

Claude Code は、この半年の開発の主軸でした。面白かったのは、使い込むうちに「コードを書かせるツール」から「振る舞いを設計するツール」に見え方が変わったことです。
どう動いてほしいか、何を守ってほしいか、どこで止まってほしいか——そういう「AIの作法」を設計するレイヤーに、自分の時間が移っていきました。
ここでも「生成より設計・統制」というテーマが繰り返し顔を出します。

エージェント型のデスクトップツールでは、自分が一行もコードを書かずに、それなりの規模のインタラクティブな成果物を完成させる体験をしました。これは率直に衝撃でした。ただし、ここでも学びは同じです。
「作れる」ことと「運用・検証できる」ことは別物だ、ということ。ゼロコードで動くものが手に入っても、それが正しく動いていると確認する責任までゼロにはなりません。むしろ自分が書いていないぶん、検証の重みは増します。

使い捨て前提のクラウド開発環境も地味に効きました。手元のマシンの都合に縛られず、必要なときだけ立ち上げて使い、終わったら止める。構成自体をコード化しておくと、環境ごと再現できるので、子育ての合間の細切れ時間でも「とりあえず開いてすぐ続きから」がやりやすい。時間が分断されがちな働き方とは、相性が良かったです。

マイクロ法人・子育てという制約から見えたこと

最後に、立場ならではの話を書かせてください。

私の働き方は、時間が細切れです。
まとまった集中時間はめったに取れない。普通に考えれば、これはエンジニアとしては不利な条件です。
でも、AIと半年走ってみて、この制約がむしろ思考をクリアにしてくれた面があります。

時間が限られているからこそ、「速く生成すること」より「信頼できる検証を持つこと」に投資する価値がはっきり見えました。細切れの時間で一番怖いのは、「前に自分が（あるいはAIが）やったことが、本当に正しかったのか」をいちいち疑い直さなければいけない状態です。検証の杭がしっかり打ってあれば、続きから安心して走れる。生成の速さは、検証の信頼があって初めて活きる。

そしてもう一つ。個人として競争優位がどこにあるか、という問いにも、半年かけて自分なりの答えが出ました。

横断的に「何でも生成できる基盤」を作る勝負は、大きな資本を持つプレイヤーの土俵です。個人がそこで正面から戦うのは筋が悪い。個人が戦えるのは、生成されたものを「現場に安全に導入し、検証し、責任を持って通す」レイヤーだと、いまは考えています。生成は誰でも手に入る時代だからこそ、「それを信用していいかを判断する」ところに、人間と、人間の経験の価値が残る。

これは負け惜しみではなく、半年の実感です。AIが賢くなるほど、皮肉なことに「最後に人間が判断する」工程の価値は下がるどころか上がりました。生成が無料になるほど、検証の希少性が際立つからです。

まとめ：上半期の学び

長くなったので、要点を凝縮します。

ボトルネックが移動した。 「書く」から「正しいと確認する」へ。AI活用の本質は効率化ではなく役割の再定義だった。
AIは検証も「やってるフリ」ができる。 trust laundering（信頼のロンダリング）に注意。各工程がもっともらしくても、誰も検証していない状態は簡単に生まれる。
委譲できるもの／できないものを分ける。 生成・修正・整形は渡せる。最終的な合否判定と検証の責任は人間に残す。
自動化するほど検証の網は細かくする。 自己正当化ループ、理解の空洞化、意図しない指示の混入——速さの代償は、たいてい検証の難しさとして返ってくる。
個人の優位は「導入と検証」のレイヤーにある。 生成基盤の勝負ではなく、現場に安全に通すところで戦う。

「AIで楽になった」という感覚は、半分正しくて半分嘘でした。楽になった部分はある。でも本当に起きたのは、自分が何のプロフェッショナルなのかが、静かに書き換わったことです。私はもう「コードを書く人」ではなく、「AIが書いたものを信用していいか判断する人」になりつつある。たぶん、これは私だけの話ではないはずです。

下半期に向けて

下半期は、この「検証をどこまで仕組み化し、どこから人が見るか」の線引きを、もう少しちゃんと言語化したいと思っています。
感覚でやっている部分が多いので、再現性のある形に落とせれば、同じようにAIと格闘している人の役に立つはずです。

そして、悩みながらでもこうしてアウトプットを出し続けること自体が、自分にとっての検証だったりもします。書くと、考えが整理されて、自分の前提のあやしさに気づく。AIに第一稿を任せられる時代でも、最後に「これは本当に自分が思っていることか」を確かめる作業だけは、やっぱり自分でやるしかない。

ここでも結論は同じでした。検証は委譲できない。

最後まで読んでいただき、ありがとうございました。同じように「AIに任せること／任せないこと」の線引きで悩んでいる方がいたら、ぜひコメントで意見を交換できたら嬉しいです。