何か本当に意味のあるツールを導入する際の私の経験では、必ず3つの段階を経てきた。（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. セッションを、別々の明確で実行可能なタスクに分割する。1つの巨大なセッションで「フクロウを描け」をやろうとしないこと。
2. 曖昧な依頼の場合は、計画と実行のセッションを分けること。
3. エージェントに自分の仕事を検証する手段を与えれば、たいていの場合、自分で間違いを修正し、リグレッションを防いでくれる。

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

こうしたことすべてが大幅な効率向上につながり、エージェントを自然に使っても自分でやるのと遜色ない速さだと感じられるまでになった（ただし、ほとんどエージェントの子守りをしていたので、速くなったという感覚はまだなかった）。

ここで余白についても繰り返しておく価値がある。効率向上の一部は、いつエージェントに頼るべきでないかを理解することにあった。失敗する可能性が高いことにエージェントを使うのは明らかに大きな時間の無駄であり、それを避ける知識を持つだけで時間の節約になる²。

この段階では、エージェントに十分な価値を見出し、ワークフローで使うことに満足していたが、純粋な効率向上を実感するには至っていなかった。ただ、その時点ではAIを一つの道具として満足していたので、気にはならなかった。

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

効率を上げるために、次に新しいパターンを始めた。毎日の最後の30分を確保して、1つ以上のエージェントを走らせるというものだ。もしかすると、どうせ自分が働けない時間にエージェントが前向きな進展を生んでくれれば、効率が上がるのではないかという仮説だった。つまり、持っている時間の中でより多くをやろうとするのではなく、持っていない時間の中でより多くをやろうという発想だ。

前の取り組みと同様、最初はこれも失敗で面倒だと感じた。しかし、すぐに本当に役に立ついくつかの作業カテゴリーを見つけた。

• ディープリサーチのセッション。特定の言語で特定のライセンスタイプを持つライブラリをすべて探し出し、それぞれについて長所・短所、開発の活発さ、世間の評判などを数ページにわたる要約にまとめるといった、ある分野の調査をエージェントに依頼するもの。
• 自分が持っていたが着手する時間がなかった、曖昧なアイデアを並列のエージェントに試させること。ここで出荷できるものができるとは期待していなかったが、翌日そのタスクに取り掛かる際に、未知の未知を照らし出してくれるかもしれない。
• IssueやPRのトリアージ／レビュー。エージェントはgh（GitHub CLI）を使うのが得意なので、大量のエージェントを並列で立ち上げてIssueのトリアージを行う簡単なスクリプトを手作業で用意した。エージェントに返信させることは決してせず、翌日にレポートだけが欲しかった。高価値あるいは低労力のタスクへ自分を導くための指針にするためだ。

はっきりさせておくと、他の人のように一晩中エージェントをループで走らせるようなことはしなかった。ほとんどの場合、エージェントは30分以内にタスクを完了した。ただ、就業時間の後半はたいてい疲れていてフロー状態から抜けており、自分自身が非効率になっていると感じるため、労力をこれらのエージェントの立ち上げに回すことで、翌朝の「ウォームスタート」につながり、そうしなければ得られなかったよりも素早く作業に入れるようになった。

満足していたし、ほんのわずかではあるが、AI以前よりも多くのことができているように感じ始めていた。

ステップ4：確実に勝てる仕事をアウトソースする

この時点で、自分のAIが何を得意とし、何を不得意とするのか、かなり自信が持てるようになっていた。特定のタスクについては、AIがほぼ正しい解決策を出すだろうという強い確信があった。そこで次のステップは、その種の仕事はすべてエージェントにやらせ、その間に自分は別のタスクに取り組むことだった。

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

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

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

重要なことに、「別のことに取り組む」というやり方は、大きな話題となったAnthropicのスキル形成に関する論文の問題を相殺するのに役立つと思う。もちろんトレードオフはある。エージェントに任せたタスクではスキルが形成されない代わりに、手作業で続けているタスクでは自然にスキルが形成され続けるのだ。

この時点で、私は完全に「もう後戻りはできない」という領域に入っていた。より効率的になったと感じたが、たとえそうでなかったとしても、一番気に入ったのは、あまり好きではないタスクも適切にこなしつつ、本当に好きなタスクにコーディングや思考を集中できるようになったことだった。

ステップ5：ハーネスをエンジニアリングする

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

これに対して広く業界で受け入れられた用語があるのかはわからないが、私はこれを「ハーネスエンジニアリング」と呼ぶようになった。エージェントがミスをするたびに、そのミスを二度と起こさないような仕組みをエンジニアリングする、という考え方だ。ここで新しい用語を作り出す必要はない。別の用語があれば、そちらに乗り換えるつもりだ。

これには2つの形がある。

1. より良い暗黙的プロンプト（AGENTS.md）。エージェントが間違ったコマンドを繰り返し実行したり、間違ったAPIを探したりといった単純なことについては、AGENTS.md（または同等のもの）を更新する。Ghosttyの例はこちら。このファイルの各行は、エージェントの悪い挙動に基づいており、それらをほぼ完全に解消してくれた。

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

これが今の私の現在地だ。エージェントが悪いことをするのを見つけるたびに、二度とその悪いことをしないようにするための真剣な取り組みをしている。逆に、エージェントが良いことをしていると検証できるようにすることにも真剣に取り組んでいる。

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

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

特に、Ampのdeep mode（基本的にはGPT-5.2-Codex）のような、遅いがより思慮深いモデルと組み合わせるのが気に入っている。これらは小さな変更に30分以上かかることもあるが、裏を返せば非常に良い結果を出す傾向がある。

私は（まだ？）複数のエージェントを並行して走らせてはいないし、今のところそうしたいともあまり思わない。1つのエージェントを走らせておくことが、楽しいと感じる深い手作業と、ちょっと愚かだが不思議と生産的なロボットの友人の子守りとの間で、今の私にとって良いバランスだと感じている。

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

今

そして、それが今日の私の現在地だ。

この旅を通じて、私は個人的に現代のAIツールで成果を出せる地点に到達し、現実に根ざした適切で冷静な見方で向き合えていると思う。AIがこの先も残るかどうかは³正直どちらでも構わない。私はただ、作ること自体を愛するソフトウェア職人なのだ。

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

私はここで何の利害関係も持っていない⁴し、有用性以外にもAIの使用を避ける理由がもちろんある。AIに関する各自の判断は全面的に尊重する。あなたを説得しに来たわけではない！興味のある人に向けて、AIに限らず一般的に新しいツールにどう向き合っているのかという、私なりの個人的なアプローチを共有し、その一端を垣間見てもらいたかっただけだ。