何か本当に役立つ道具を身につけようとするとき、私は必ず三つの段階を経てきました。（1）非効率な時期、（2）なんとか使えるようになる時期、そして最後に（3）ワークフローや生き方まで変えてしまうような発見の時期です。

ほとんどの場合、フェーズ1と2は自分自身を無理やり前に進めなければなりません。すでに気に入っていて心地よいワークフローがあるからです。新しい道具を取り入れるのはそれ自体が仕事のように感じられ、正直、できれば手間はかけたくありません。それでも、自分の技術を偏りなく磨きたいという思いから、結局は取り組むようにしています。

この記事は、私がAIツールにどのように価値を見出し、次に何を試そうとしているのか、その歩みを綴ったものです。大げさに盛り上がった論調が溢れる中で、AIに対する私の見方がどのように変わってきたのか、少しでもバランスの取れた、落ち着いた視点として伝わればと思っています。

ステップ1：チャットボットを捨てる

本格的な作業をチャットボット（例えばウェブ版のChatGPTやGeminiなど）でやろうとするのは、すぐにやめることをお勧めします。チャットボット自体には確かな価値があり、私自身も毎日のAIワークフローで使っています。しかし、コーディングにおける有用性は非常に限られています。事前学習をもとに正しい結果を出してくれることを祈るだけで、間違いを正すには人間（つまり自分自身）が何度も誤りを指摘しなければならないからです。非効率なのです。

誰にとっても、AIとの最初の出会いはチャットインターフェースだったと思います。そして、AIでコーディングを試す最初の経験も、チャットにコードを書かせることだったはずです。

私自身、まだかなりのAI懐疑派だった頃、最初の「おお、すごい」という体験は、ZedのコマンドパレットのスクリーンショットをGeminiに貼り付け、SwiftUIで再現するよう頼んだときでした。結果は驚くほど見事で、本当に度肝を抜かれました。現在GhosttyのmacOS版に搭載されているコマンドパレットは、Geminiが数秒で生成してくれたものに、ほんの少し手を加えただけのものなのです。

しかし、同じことを他のタスクで再現しようとすると、がっかりさせられることが続きました。とくに既存のプロジェクト（ブラウンフィールド）では、チャットインターフェースが出す結果は質が低いことが多く、コードやコマンドの出力をコピー＆ペーストして往復させる作業に強いフラストレーションを感じました。自分でやった方が明らかにずっと効率的だったのです。

価値を引き出すには、エージェントを使わなければなりません。エージェントとは、チャットをしながら外部の動作をループで実行できるLLMを指す、業界で定着した呼び方です¹。最低限、エージェントには次のことができなければなりません。ファイルを読み取ること、プログラムを実行すること、そしてHTTPリクエストを送ることです。

ステップ2：自分の仕事を再現させる

次の段階では、Claude Codeを試しました。結論から言えば、最初はあまり感心しませんでした。セッションから良い結果が得られず、生成されたものはすべて手を入れる必要があり、結局自分でやった方が早いと感じるほど時間がかかっていました。ブログ記事を読んだり動画を見たりもしましたが、やはり心は動きませんでした。

そこで諦める代わりに、自分の手作業によるコミットをすべて、エージェントによるコミットで再現することを自らに課しました。文字どおり仕事を二回やったのです。まず手作業でやり遂げ、次にエージェントと格闘しながら、品質も機能も同等の結果を（もちろんエージェントには自分の手作業の解答を見せない形で）作らせるようにしました。

これは本当に苦痛でした。単に物事を片付けることの邪魔になるからです。しかし、AI以外の道具でも経験を重ねてきたからこそ、こうした摩擦は自然なことだと分かっていました。やり尽くさなければ、確信を持って語れる結論にはたどり着けません。

しかし、その過程で確かな勘所が身についていきました。すでに多くの人が語っていたことを、自分の手で第一原理から再発見したのです。自分で見つけたことで、より根底からの理解につながりました。

1. セッションは、明確で実行可能なタスクごとに分割します。一つの巨大なセッションで「一気にフクロウを描こう」としないことです。
2. 曖昧な依頼の場合は、計画と実行のセッションを分けます。
3. エージェントに自分の仕事を検証する手段を与えれば、たいていの場合、自ら間違いを修正し、リグレッションを防いでくれます。

より一般的には、当時のエージェントが何を得意とし、何を苦手としているのか、その境界も見えてきました。そして得意なタスクについては、どうすれば望む結果を得られるのかも分かってきました。

これらすべてが大きな効率向上につながり、エージェントを自然に使っても、自分でやるのと比べて遅くないと感じられるようになりました（とはいえ、まだエージェントの子守をしている感覚だったので、速くなったとは思えませんでした）。

ここであえて強調しておきたい「余白」があります。効率向上の一部は、エージェントに頼らない方がいい場面を見極められるようになったことでした。失敗する可能性が高いことにエージェントを使うのは明らかに大きな時間の無駄であり、それを避ける知識自体が時間の節約になります²。

この段階では、エージェントに十分な価値を見出し、ワークフローに組み込むことに満足していました。ただ、正味の効率向上を実感するまでには至っていませんでした。それでも構わないと思えました。この時点では、AIを一つの道具として受け入れられていたからです。

ステップ3：終業時のエージェント

効率化をさらに探るため、次に新しい習慣を始めました。毎日最後の30分を確保して、一つ以上のエージェントを走らせるのです。仮説はこうでした。自分がそもそも作業できない時間に、エージェントが少しでも前向きな進捗を作れれば、効率は上がるのではないか、ということです。つまり、持っている時間の中でより多くをこなそうとするのではなく、持っていない時間の中でより多くをこなそうという発想です。

前回と同様、最初はうまくいかず、煩わしく感じました。しかし、すぐに本当に役立つ作業のカテゴリーがいくつか見つかりました。

• ディープリサーチのセッションでは、特定の言語で特定のライセンスを持つライブラリをすべて探し出し、それぞれについて長所・短所、開発の活発さ、コミュニティでの評判などを数ページにわたるサマリーにまとめるといった、ある分野の調査をエージェントに依頼します。
• 漠然としたアイデアを並列で試させることです。思いついたもののなかなか手をつけられないアイデアを、複数のエージェントに並列で試させました。ここで作られたものをそのまま製品にすることは期待していませんでしたが、翌日本格的に取りかかる際に、未知の未知を照らし出してくれるかもしれないと考えたのです。
• IssueやPRのトリアージ／レビューです。エージェントはgh（GitHub CLI）の扱いが得意なので、多数のエージェントを並列で立ち上げてトリアージを行う簡単なスクリプトを自作しました。エージェントに直接返信させることは決してせず、翌日にレポートだけを受け取り、価値が高い、あるいは工数が少ないタスクへ自分を導く手がかりにしました。

念のため付け加えると、他の方のように一晩中エージェントをループで走らせるようなことはしませんでした。ほとんどの場合、エージェントは30分以内にタスクを終えていました。ただ、就業時間の後半は疲れていてフロー状態から抜け、どうしても自分の効率が落ちてしまいます。そうした時間にエージェントを立ち上げる方へ労力をシフトすることで、翌朝「ウォームスタート」ができるようになり、そうしなかった場合よりも素早く仕事に入れるようになりました。

満足していましたし、わずかではあっても、AI以前よりも多くのことをこなせている感覚が出てきました。

ステップ4：確実な仕事は任せる

この頃には、AIが得意なタスクとそうでないタスクがかなりはっきり分かるようになっていました。ある種のタスクについては、AIがほぼ正しい解を出すだろうという強い確信が持てていました。そこで次のステップは、そうした作業はすべてエージェントに任せ、その間に自分は別の作業に集中することでした。

具体的には、毎朝、前夜に走らせたトリアージエージェントの結果を見直し、エージェントがほぼ確実にうまく解決できそうなIssueを手作業で絞り込み、それらをバックグラウンドで一つずつ（並列ではなく）走らせ続けるようにしました。

その間、私は別の作業に取り組みました。SNSを見に行くわけでも（AIがない頃と比べて特に増えたわけでもなく）、動画を見るわけでもありません。AI以前と同じように、深く思考する通常のモードで、やりたいこと、あるいはやらなければならないことに取り組んでいました。

この段階で非常に重要なのは、エージェントのデスクトップ通知をオフにすることです。コンテキストスイッチは非常にコストが高いからです。効率を保つには、人間である自分がいつエージェントを中断するかをコントロールすべきで、その逆であってはならないと気づきました。エージェントに通知させてはいけません。作業の自然な区切りでタブを切り替えて様子を確認し、また作業に戻ればいいのです。

重要なことに、「別の作業に取り組む」という姿勢は、広く話題になったAnthropicのスキル形成に関する論文への対抗策にもなると考えています。もちろんトレードオフはあります。エージェントに任せたタスクではスキルが身につかなくなる一方で、手作業で続けているタスクでは自然にスキルを磨き続けられるのです。

この時点で、もはや「後戻りはできない」という領域にしっかりと入っていました。効率は上がったと感じていましたが、たとえそうでなかったとしても、一番気に入ったのは、本当に好きなコーディングや思考に集中しながら、そうでないタスクも十分にこなせるようになったことでした。

ステップ5：ハーネスを作り込む

当たり前のことを言うようですが、エージェントは一発で正しい結果を出すとき、あるいは最低限の手直しで済む結果を出すときに、最も効率的です。これを確実に実現する最善の方法は、間違っているときに自動で教えてくれる、高速で高品質なツールを与えることです。

これに対して広く業界で合意された用語があるのかは分かりませんが、私はこれを「ハーネスエンジニアリング」と呼ぶようになりました。エージェントがミスをするたびに、そのミスを二度と繰り返さないように仕組みを作り込む、という考え方です。新しい用語を作るつもりはありません。別の定着した呼び方があれば、喜んでそちらに乗り換えます。

これは大きく二つの形で現れます。

1. より良い暗黙的なプロンプト（AGENTS.md）です。エージェントが誤ったコマンドを繰り返したり、間違ったAPIを探したりするような単純な問題であれば、AGENTS.md（あるいはそれに相当するもの）を更新します。Ghosttyの例はこちらです。このファイルの各行は、エージェントの望ましくない挙動をもとに書かれたもので、それだけでほぼすべての問題が解消されました。

2. 実際にプログラムされたツールです。たとえばスクリーンショットを撮るスクリプトや、絞り込んだテストを実行するスクリプトなどです。これは通常、その存在をエージェントに知らせるためのAGENTS.mdの変更とセットで使われます。

これが今の私の現在地です。エージェントが良くない挙動をしたのを見かけるたびに、二度と繰り返さないようにするべく真剣に取り組んでいます。逆に、良い挙動をしていることをエージェント自身が検証できるようにすることにも、同じく真剣に取り組んでいます。

ステップ6：常にエージェントを走らせておく

ステップ5と並行して、「常にエージェントを走らせておく」という目標も掲げています。エージェントが動いていないときは、「今、エージェントに任せられることはないか？」と自問するようにしています。

とくに、Ampのdeep mode（実質的にはGPT-5.2-Codexです）のような、速度は遅いもののより深く考えるモデルと組み合わせるのが気に入っています。小さな変更に30分以上かかることもありますが、裏を返せば非常に良い結果を出す傾向があります。

私は（まだ？）複数のエージェントを同時に走らせてはいませんし、今のところそうしたいとも思っていません。一つのエージェントを走らせておくのが、楽しさを感じられる深い手作業と、どこか抜けていて、それでいて不思議なほど生産的なロボットの友人の子守との間で、今の自分にとってちょうど良いバランスなのです。

「常にエージェントを走らせておく」という目標は、まだ目標のままです。今のところ、通常の勤務時間の10〜20％程度でバックグラウンドのエージェントを走らせられているのが実情だと思います。ただ、これを改善するために積極的に取り組んでいるところです。

現在

そして、これが今の私の現在地です。

この歩みを通じて、私自身、現代のAIツールで成果を出せる段階にたどり着き、地に足のついた、適切で冷静な向き合い方ができていると感じています。AIがこの先定着するかどうかは、正直どちらでも構いません³。私はただ、作ることそのものが好きでものを作りたい、ソフトウェアの職人なのです。

状況はあまりにも速く動いているので、すぐにこの記事を振り返って自分の未熟さを笑うことになるでしょう。でも、よく言われるように、過去の自分を恥ずかしく思えないなら、成長していない証拠です。ただ、正しい方向に成長できればと願っています！

私はここで何の利害関係も持っていません⁴し、実用性以外にもAIの利用を避ける理由があることももちろん理解しています。各自の判断は全面的に尊重します。誰かを説得するために書いているわけではありません！興味のある方に向けて、こうした新しい道具とどう向き合っているのか、そしてAIに限らず新しい道具一般にどう向き合っているのか、私なりのアプローチを共有したかっただけです。