AIエージェントのススメ 第16回 AIエージェントを使った開発のまとめ その1
シリーズのまとめとして、AIエージェントを使った開発について5つのテーマを2回に分けて取り上げます。今回は、ワークフローの見直し、自分の領域の広げ方、AIの情報との距離の取り方について、筆者の経験をもとに考えます。
シリーズを締めくくる5つのテーマ
今回と次回の2回に分けて、シリーズのまとめとして、AIエージェントを使った開発について、次の5つのテーマを取り上げます。
- これまでのワークフローを見直す
- 自分の領域を広げる
- AIの情報を追いかけすぎない
- 開発するだけでは稼げない時代に、何で価値を出すか
- 「作りたい」という意欲が、何よりも大切になる
今回は、1〜3のテーマを1つずつ見ていきましょう。
1. これまでのワークフローを見直す
最初のテーマは、ワークフロー、つまりは自分自身の開発に対するやり方自体を変えることです。AIを使った開発では、ごく基本的な話となるでしょう。ただ、実際にその変化についていくのは、なかなか難しいと感じている人が多いように思います。
これまで私たちは、自分の手でコードを書いたり、PhotoshopやFigmaのようなソフトを使ったりと、自分で操作することに多くの時間を費やしてきました。その操作自体が、仕事の大きな部分を占めていたからかもしれません。では、これまでのやり方を、どう変えればよいのでしょうか。
筆者の経験上、「自分の作ったbig-planという便利なスキルがあるので、Claude Codeを使うなら、これをこう使えばいいですよ」といった手順の紹介だけでは、うまくいかないと考えています。そうした説明では、AIを使ううえでの根本的な部分が抜け落ちてしまうからです。
このシリーズでも何度か書いていますが、こういったAIエージェントへの指示というのは、ただテキストを与えるだけなのです。それがまず第一歩。そしてその先を続けるときにどうするか、この試行錯誤自体がAIを使った開発のフローそのものだと言えます。これを身につけるには、一人ひとりが自分なりのやり方を作っていく必要があるでしょう。端的に言えば、経験を自分で積むしかないということです。
CodeGrid編集チームの取り組み
最近、CodeGridの編集チームが取り組んだことを紹介します。
編集チームでは、毎週の記事公開後に、著者にSNSでの記事紹介を促すメッセージを社内Slackのチャンネルへ投稿するボットを作りました。記事をSNSでもっと広めるための仕組みです。新しい記事が公開されたあとに編集チームがSlackのスラッシュコマンドを入力すると、最新記事を参照して、著者宛に次のような記事の拡散を促すメッセージが投稿されます。
この仕組みをどう作ったか、編集チームのメンバーが、社内で毎週開いている勉強会で紹介してくれました。使ったのはGoogle Apps Script、いわゆるGASです。
最初はローカルでClaude Codeとやり取りし、出てきたコードをGASの画面にコピー＆ペーストしていたそうです。でも、繰り返すうちに「これ、自分たちはコピペしているだけでは？」と感じたとのこと。そこで、Claude CodeにChromeを直接確認してもらい、ブラウザ上でのコーディング作業も任せるようにしたそうです。
自動化したくなる気持ち
これは、仕事の仕方が変わっていく、とてもよい例だと思います。想像してみてください。「SlackでSNSポストを促す投稿をしたいんだよね」という社内メンバーがいて、「ほらこのスキルを使えばできるよ」と答えを与えるような状況を。課題を解決するにはそれで十分ではありますが、もしそのメンバーが自分の手でAIの使い方を覚えたいという意思をもっていたら、その芽を摘むようなアドバイスになってしまうかもしれません。
ここで大事なのは、GASを選んで使ったことではありません。次のような流れそれ自体です。
- AIと何かを試してみる。多くの場合は、チャットから始まる。
- スキルや自動化などを使えば、もっと楽にできそうだと気づき、試みる。
大切なのは、2つ目です。ここには「もっと楽にしたい」という意欲が必要です。なぜなら、1つ目のやり方を、そのまま続けることは容易で、何も考えなくて済むからです。以前なら、2つ目に挑戦するには相応の手間がかかりました。でも今は、そうではありません。もちろん、AIが手伝ってくれるからです。
こうした作業は、どれもAIで改善していけます。早く仕事を終わらせたい開発者は、そのことに気づき、開発環境の改善を続けていきます。その結果、自分ではコードを書かずに開発するようになっていくわけです。
では、それが日々の開発になると、どうなるでしょうか。今度は、AIエージェントの作業が終わるのを待つ時間が生まれます。すると、また別のことを考え始めます。「Git worktreeを使えば、もっと進められるのでは」「複数のエージェントを並行して動かしてみよう」「複数のマシンで並行開発しよう」といった具合です。
以前なら、同時に進められる仕事を増やすには、チームの人数を増やす必要がありました。今は、AIを使ってそれができるようになっています。
学んでから作るから、作ってから学ぶに
ワークフローということで言えば、特に筆者の場合、大きく変わったのは、学習と開発の順番です。これが完全に逆転しました。
- A：学ぶ → 開発する
- B：開発する → 学ぶ
これまでは、基本的にAでした。コードの書き方を学ばずに、アプリやWebサイトを作ることはできません。当然です。買ってきた書籍についてきたサンプルアプリを読み解き、それを真似てみる、不足している部分はGoogleで検索して調べる……という方法で我々は技術を身につけてきました。でも今はBです。やりたいことをAIに伝えれば、AIがコードを書いてくれます。この変化のすごいところは、Bのほうが圧倒的に速く、間口も広いことです。
筆者にとっては、Cloudflareを突っ込んで使い始めたときが、まさにそうでした。「Cloudflareを使って、こんなWebアプリを作って、メモをCloudflareの何かで保存して、ログインできるようにして」などと、AIにざっくり依頼します。するとAIは、R2やD1、Workersなどを使ってアプリを作ります。できあがってから、「D1って何？」「KVや一般的なデータベースとは、どう違うの？」とAIに聞くわけです。
最初からゴールが出され、さらにそこから詳しく聞くことができるのです。Aと比べたら、こちらのほうがどう考えても速いでしょう。
出発点は、どちらも同じです。「アプリを作ってみよう。さて、何から始めようか」。ただ今は、一度にずっと高い段まで上れるようになった。その方法を選ぶかどうかは、一人ひとりに委ねられています。これまでどおりのやり方を続けることもできるので、そこは意識して飛躍することが必要なのかもしれません。
2. 自分の領域を広げる
2つ目のテーマは、自分の領域を広げることです。AIの助けがあれば、これまで自分の専門外だった仕事についても、以前よりずっと学びやすくなります。
「フロントエンド開発者」という枠を超える
自分の身近な領域でいうと、「フロントエンド開発者」という呼び方が、少し古く感じられるようになりました。前の節でも書いたように、今はフロントエンドの開発者がバックエンドの開発に手を伸ばすことも、それほど難しくありません。
たとえば、フロントエンドの開発者は、これまでもAPIの仕様には触れてきたはずです。筆者もそうです。そして今は、APIの仕様がわかっていれば、少し手をかけるだけで、その裏側の実装もAIに任せられます。
もちろん、それぞれの分野には奥深さがあります。ここで言いたいのは、AIの力を借りることで、隣接する領域にもずっと手を伸ばしやすくなった、ということです。
開発者もデザインに取り組める
AIを使って開発するようになってから、筆者は前回の記事で紹介した個人プロジェクトであるzudo-docのようなパッケージだったり、Webサービスだったりを大量に作っています。そうなれば当然、画面のデザインも必要です。
こうした仕事は、これまでデザイナーの専門領域でした。自分でもできないわけではありませんが、時間がかかりますし、端的に言って高品質なものを作れるという自負もありません。でも今は、フロントエンドの開発者なら、そこもかなり速いペースで学んでいけると感じています。
筆者の場合、そういった画面UIを考えるとき、もしくはUI改善をしたい場合、まずAIエージェントに、プロトタイプやUIの改善案を10パターンほど作ってもらいます。「たぶんアイコンのメニューがあるとよさそう」とか「タブみたいなUIで切り替えるといいかも？」とか、思いついた言葉をタイプするだけです。端的に言えば「なんかそれっぽいの考えて！」という投げ方です。そうするとたくさんパターンを作ってくれます。それを見て細部を考え、フィードバックを返し、また別案だったり改善案だったりを作ってもらう。「これでよさそうだ」と思えるまで繰り返し、それから実装に進みます。
要するに、AIエージェントに、ああだこうだと注文をつけているだけです。それでも、その対話の中で学びがあり、そして自分も方向性を示さねばならず、必然的に考えさせられます。そうやってデザインの経験が間接的に積み重なっていきます。フロント周りの開発をしている人であれば、当然画面を作ったりしているでしょうから、これまでやってきたことの地続きのように感じられるのではないかと筆者は考えます。
それはデザインだけではありません。筆者の個人プロジェクトの電子回路開発でも、同じようなことが起きています。学ぶ過程で物はすでにできているので、物ができるのと同時に学習も進む。結果、隣接分野の経験が急速に蓄積されていきます。これを昔ながらの方法でやっていたとしたら大変な労力です。ただ今は違います。それも何か特別な技能が必要なわけではなく、ただチャットしてるだけでいいんですから。
3. AIの情報を追いかけすぎない
3つ目は、「AIの情報を追いかけすぎない」という話です。こんな記事を書いているのに？ と思われるかもしれませんが。
理由は単純で、そうした情報は、あまりにも早く古くなってしまうからです。今の時代、特に自分の時間を何に使うか、よく考える必要があると思います。
モデルや機能を追いかけること
たとえば、Claude CodeやCodexでは、モデルを選べます。しかし、ここで特に深入りしすぎないほうがよいと筆者が思うのは、次のような話です。
- OpusはSolより優れているのか？
- 下位モデルをうまく使うには、どういうスキルが最適なのか？
- AstraとSolでは、トークンの消費量がどのくらい違うのか？
もちろん、自分の時間を何に使うかは自由ですから、調べたり試したりすることを止めるつもりはありません。ただ、自分は何のためにAIを使っているのか、ということを忘れてしまうと、1ヶ月後には何の役にも立たない情報をひたすら追っているみたいな状態に、簡単に陥ることでしょう。
iOSアプリを作りたいなら、AIを使ってiOSアプリを作ればよい。その過程で、必要な知識は自然と身についていきます。そのほうが、時間の使い方として賢いであろうと筆者は考えます。
ノウハウはすぐに古くなる
そう書くのは、私自身、そうしたことにかなりの時間を使ってきたからです。
たとえば以前、Copilotに無料で使える安いモデルがあったので、GitHub Copilot CLIとClaude Codeを組み合わせて節約しようとしたことがあります。もともと連携を前提にしたものではないので苦労し、何日もかけました。ところがその後、GitHub Copilotの料金は大きく上がり、無料モデルもなくなりました。今ではまったく使い道のないノウハウです。あの労力は、本当に作りたかったものに使えばよかったと思います。
私たちはAIに、何かを作るための道具として料金を払っています。その道具を使うために手間をかけすぎるのは、本来やりたかったことではないはずです。技術者気質だと、効率化そのものが楽しくなってしまう気持ちはよくわかります。だからこそ筆者は、面倒くささが我慢の閾値を超えるまで、効率化には手を出さないようにしています。
AIをヘビーに使う開発では、いくつものエージェントに返事をしているだけで一日が終わってしまいます。ノウハウやツールの深掘りはメインの実装を後回しにすることになるので、本当にそれが必要か、いつそこに時間を割くかを見極める必要があるのです。
スキルも古くなる
このシリーズでは、世間でよく知られている著名なスキルの紹介のような内容は、あえて避けるようにしていました。たとえばsuperpowersという、GitHubのスターが29万近くあるスキルがあります。これはもともとブレインストーミング、計画、TDD（テスト駆動開発）などのフローを組んでくれるもので、それだけ聞くと便利そうですが、こういう情報も、追いかけすぎには注意が必要です。
スキルは、基本的にはMarkdownのテキストファイルです。LLMが更新されれば、その指示に対する挙動も変わります。たとえば「デザインを改善して」「コードの設計を見直して」といった指示も、数ヶ月後には、それだけでずっとよい結果が出るようになります。AnthropicもOpenAIも、新しいモデルが出ると、スキルを見直すように、そして単純にするようにという話を毎回のようにしています。
これは特に能力の高いモデルで顕著であるように筆者も感じます。たとえばChatGPTのチャットで最上位モデルのAstraを使うと、適当に「Slackにポストする仕組みをCloudflareで作って、API叩いて呼びたい」みたいなことを言うだけで、全部作ってzipにして返してくれます。前述のUIプロトタイプみたいなものも丸っと作って返してくれます。スキルも何も使わなくても可能です。
1年前、2025年秋あたりのことを思い出すと、そういう実装をAIに的確にやらせようと皆が奮闘し、superpowersのようなスキルが生まれたのですが、今はわざわざそういう情報を与えなくとも、AIがよしなにやってくれるようになっています。これは単純にモデルの進化の恩恵であり、そういう基礎的な開発のフローは、もはや指示する必要がないというより、蛇足でトークンを無駄に使うだけの情報になっているのです。
ですから、「今はこのスキルを使うのが最強！」みたいな情報は、基本的には今このときという前提があります。そういったスキルを使うことを否定したいわけではありません。ただ、誰かが作ったものをそのまま使い続けるより、自分の用途に合わせて手を入れ、自分のスキルにしていくことを勧めます。そうしないと、また新しいバージョンのLLMが登場したとき、自分の手札をわかっていない状態になってしまうでしょう（なお、superpowers自体はその後薄いハーネスへと内容が変化したようです）。
必要になるまで学ばなくてもよい
もう1つ、筆者の例を挙げます。開発上の課題ごとに、AIエージェントにGitHubのIssueを立ててもらい、終わったら閉じさせているので、毎日1000通以上の通知メールが届きます。そこで、それらをまとめてアーカイブする/gm-cleanというスキルを作りました。
- やりたかったこと：大量に届くメールをアーカイブしたい。
- ゴール：Claude Codeでスキルを実行するだけで、それらをアーカイブできるようにする。
このとき、私はClaude Codeに、こう聞いただけでした。
「Takazudoの個人リポジトリから届くGmailの通知メールをアーカイブしたい。条件は○○で××なメール。これをスキルにしたいんだけど、どうすればいい？」
するとClaude Codeがスキルを作り、Google Cloudでのアプリの設定方法も案内してくれました。それで十分でした。
この記事の最初の話を思い出してください。「学ぶ → 開発する」という順番は、今は逆になっています。「開発する → 学ぶ」ができるぞと。技術的には、Google CloudのAPIや、Gmail APIを扱うOSSのツールが必要でしたが、筆者がやったことは、Claude Codeに「こうしたい」と伝えたのがすべてです。その結果、「なるほど、こういう仕組みでGmailを操作できるのか」ということも学べました。「これはよさそうだ。また何かに使えるかもしれない」。そのくらいでよいと思います。
ここで伝えたいのは、基本的に、必要になるまで学ばなくてもよいということです。こうした便利そうな効率化の実現方法を、先回りして追いかけすぎないほうがよいと思います。なぜなら、その部分はAIがやってくれるからであり、そして今や我々ができる範囲は、とんでもなく広がってしまっているためです。全部学ぶのは無理です。AIに任せられる部分は任せる判断をし、諦めましょう。
大切なのは、そもそも何をしたくてAIを使っているのかを意識することです。何かを効率よく進めたくて使い始めたはずなのに、AIそのものに時間をかけすぎてしまっては、本来の目的から離れてしまいます。
今回は、AIエージェントを使った開発について、筆者が考える5つのテーマのうち、最初の3つを取り上げました。次回は、残りの2つのテーマ、開発で収入を得ることが難しい時代にどう価値を出すかと、「作りたい」という意欲の大切さについて考えます。