関数の指示から、目標の達成へ

Claude Code は、開発者のプログラミング作業を支援する AI ツールです。インタビューでは、チームが使用・開発中の Slack ネイティブエージェントである Claude Tag についても紹介されました。Slack はチームコミュニケーションツールであり、Claude Tag はそこでタスクを受け取るだけでなく、製品に関する議論やチームの決定事項を閲覧することもできます。

あるメンバーは、自分の仕事の約 70%〜80% が Claude Tag 内で発生していると推定しています。残りの一部は、ターミナルインターフェースやデスクトップアプリケーションを開いて微調整を行います。これは個人の使用方法ですが、会話の入り口がチームの日常的なコラボレーションの場に移り、Claude に任せる問題が「このクラスを実装する」や「この関数を作成する」といった範囲をはるかに超えていることを示しています。

製品がなぜこのように設計されたのか、チームがどのような選択肢を断念したのか、特定の決定の背後にある制約は何か。こうした情報は、コードの中には存在しないことがよくあります。コードベースのみでは、モデルは「どうやって実装するか」は分かるかもしれません。しかし、議論や決定の背景が加わることで、「このチームの目標に合致する方法」を判断できる可能性が高まります。

人間が注意を向ける点も変わっています。以前は、ツール呼び出しやモデルの判断を一つずつ細かく確認していました。現在は、目標を提示し、Claude が結果を持ち帰るのを待つ場面が増えています。例えば、「指定した修正を実装してほしい」という依頼では、解決策を考えるのは人間です。「このフローを完了するユーザーを増やしてほしい」と伝えれば、状況の分析、改善案の提案、選択肢の比較まで Claude に任せられます。

このように目標レベルで委任する場合、エージェントへの要求はより高くなります。エージェントは、背景情報を取得し、作業を整理し、成果物を実行し、人間が次のステップを判断できるように結果を持ち帰る必要があります。チームがその後語ったツールの変化は、このような働き方の条件を整えるためのものでした。

目標の規模が拡大する中、補助ツールもモデルとともに進化する

チームが直面した特有の問題は、ツールが依存するモデルの能力変化が非常に速いことでした。インタビュー対象者によると、以前はひとつの技術が長年にわたって安定して使用されましたが、現在では基盤となる能力がおよそ二か月ごとに顕著に変化するとのことです。ツール開発においては、今日の問題を解決することだけでなく、どの問題がすぐに消滅する可能性があるかを見極めることも重要になっています。

ToDoリストはその一例です。Sonnet 3.5 の頃、彼らはモデルが長いタスクを処理する際に漏れが生じやすいことを発見しました。五つのことを依頼しても、三つ完了した時点で停止してしまうことがありました。リストを追加することで、パフォーマンスは改善されました。その後、モデルの能力と利用可能な記憶状態が変化し、メンバーは当時のリストが以前ほど必要ではなくなったと判断しました。

ここには絶えず変化する連鎖があります。まず、モデルの具体的な失敗を発見し、ツールで補完します。モデルが進歩したら、その補完メカニズムが依然として価値があるかを再検討します。そして、タスクを拡大すると、新たな調整や状態管理の問題に直面します。ツールは問題に合わせて変化する必要があり、各世代のモデルのパッチを積み重ね続けるべきではありません。

チームは、モデルを中心にツール、状態、実行プロセスを組織化するシステムを harness と呼んでいます。これは、モデルが作業を完了させるための実行フレームワークと理解できます。時代遅れのメカニズムを削除することは、新しいタスク形態のための設計スペースを確保することでもあります。

質問方法の進化は、別の変化を示しています。当初、メンバーは計画を立てた後に Claude がユーザーへ質問することを望みました。その後、これはモデルが自ら呼び出すことができる AskUserQuestion ツールへと変化しました。その当時は、モデルが適切に使用できるようにインターフェースを注意深く設計する必要がありました。能力が向上するにつれて、Claude は HTML の成果物を直接生成し、図、インターフェースのプロトタイプ、質問を組み合わせることができるようになりました。

例えば、インターフェース案について議論する際、人間は目に見えるプロトタイプを見ながら決定を下すことができ、双方が言葉だけで異なるインターフェースを想像する状況を減らすことができます。かつて固定されていた質問インターフェースは、今では Claude がタスクに応じて生成する成果物のひとつになりました。権限管理、可視化、質問といった基本的な機能は依然として重要ですが、これらは異なる働き方に組み合わせることができ、上位の製品は初期の形態に固定される必要はありません。

継続的な進捗のために、まず作業をノートパソコンから切り離す

目標が拡大すると、実行はしばしば一回の会話や勤務時間を超えて継続します。チームは定期的なタスクについて語る際、まず単純な障害に言及しました。エージェントがノートパソコン上で動作している場合、オフィスを離れたり、ノートパソコンを閉じたりすると、作業が停止してしまうということです。

チームはまずリモート開発マシンを使い、ノートパソコンを開いたままにする必要をなくしました。ただ、リモートマシンに接続し、作業環境に戻る手間は残りました。その後、Web から利用できるマネージドコンテナが便利な入り口となり、開発環境をリモートで継続して動かせるようになりました。

ここでは、二つの異なることを解決する必要があります。一つ目は、タスクが継続的に実行できるかどうかです。二つ目は、Claude がその環境で実際に開発を完了できるかどうかです。コードをリモートに置くだけでは不十分で、ソフトウェアを起動し、必要な依存関係にアクセスし、テストを実行し、開始から終了までの完全なフローを確認する必要があります。

Robert 氏は、Claude Tag を使って Claude Tag を開発する際、主にこれらの条件を整えることに注力していました。エージェントが開発者と同等の環境とエンドツーエンドのテスト能力を持つようにすることが重要です。ソフトウェアの依存関係の統合が複雑になればなるほど、この準備作業はより困難になり、エージェントが最終的にどこまで自律的に進められるかに影響します。

環境が安定すると、指示は継続的な責任になりやすくなります。例えば、毎日受け取ったフィードバックを確認し、重要度で分類し、確信度の高い問題を処理します。このようなループは複数回の実行にまたがり、人間が毎回同じタスクを改めて開始する必要はありません。

あるメンバーは、リモート環境を構築した後の個人的な生産性の向上について、約十倍になったと表現しています。インタビューでは測定方法は示されていません。参考になる具体的なアプローチは、実行環境の構築も委任作業の一部として捉えることです。目標に必要なアクションを、Claude が実行できる状態にすることです。

複雑なタスクでは、Claude 自身にワークフローを設計させる

複雑な目標には、もうひとつの独立した課題があります。それは、作業の分解です。チームはコードレビューを例に挙げています。まず、複数のエージェントが異なる方向から潜在的な問題を探索し、次に各候補問題について多角的なレビューを行い、最終的に人間が注目すべき重要な項目を絞り込みます。

このプロセスの鍵は、まず探索範囲を広げ、その後段階的に結果を収束させることです。

インタビューで紹介された方法は、候補となる問題を三つの異なる視点から再検討し、それが実際に存在するかどうかを判断するというものです。これにより、開発者は単に多数の可能性のある問題を受け取るのではなく、さらなる分析とフィルタリングを経た調査結果を受け取ることができます。多角的なレビューは誤検知を減らすのに役立ちますが、最終的な判断は証拠に基づいている必要があります。

彼らは、問題を解く際に推論と計算の投入を増やすことを test-time compute と呼んでいます。ここで増えるのは、現在のタスクに対する分析作業です。方向性を追加したり、レビューを複数回行ったりして、その追加作業をより有用な結果に変換します。

さらに進んで、ワークフロー自体も Claude が設計できるようになりました。人間が問題を提起すると、Claude はどのエージェントが必要か、どの方向を並行して展開するか、前の層の出力をどのように次の層へ渡すか、そして最終的にどのように集約するかを決定できます。その後、Claude はコードを書き、それらのエージェントを接続して実行します。委任範囲は、個々の分析から、分析作業をどのように組織化するかという点にまで拡大しました。

コードとモデルは、それぞれ異なる役割を担っています。プログラムループは、各項目に対して同じ一連のステップを実行し、「五つ確認すると言いながら三つしか確認しない」といった漏れを防ぎます。モデルは、各項目内で理解と判断が必要なコンテンツを担当します。プログラムはプロセスの一貫性を維持するのに役立ちますが、各分析が正しいかどうかは、別途判断する必要があります。

この方法は、一般的な調査にも使用できます。チームは、両親を Tahoe に連れて行く旅行の例を挙げました。宿泊施設やアクティビティなどの方向性をそれぞれ検索し、フィルタリング、照合、集約を行います。最終的な収束は重要です。そうでなければ、並行作業は単に多くの断片的な資料を人間に渡すだけになってしまいます。

コードレビューにおいても、人間の注意はより高いレベルへと移行しています。Claude が細かな問題を先に処理できる一方で、人間はインターフェースがなぜこのように設計されたのか、サービス境界がなぜここにあるのか、実装がチームの製品意図と一致しているかといった点を重視する価値があります。これは、冒頭のコンテキストの問題に戻ります。局所的なコードが妥当に見えても、それがシステム全体の設計上の理由と一致しているとは限りません。

各ステップを細かく監視するのではなく、確認可能な結果に基づいて協働する

ワークフローがバックグラウンドで進行するようになると、人間とエージェントのインターフェースも変化する必要があります。Claude Tag は、日常的なメッセージと完全な実行記録を分離しています。メッセージ送信はモデルが呼び出すことができるツールであり、モデルはいつ、何を人間に報告するかを選択します。プロセスを追跡する必要がある場合は、人間が完全な記録へのリンクを開くことができます。

これにより、製品インターフェースがモデルのすべての出力やツール呼び出しを同期表示する必要がなくなります。インタビュー対象者は、以前のように細部を監視できないことへの不安が最初はあったものの、その後、良い結果が繰り返し得られることで、この働き方が楽になったと述べています。インターフェースの変化は、目標、未解決の問題、成果物を中心にコミュニケーションをとる、別のタイプのコラボレーションを彼らに促しました。

この信頼を支えているのは具体的な検証です。Claude はコード変更を提出する際、テストを実行し、画面のスクリーンショットを送ります。ある社内ツールの開発者は、Claude にターミナル画面を操作する様子も録画させました。その録画を見た後、コードをローカルに取り込み、自分で試して、実際の使い心地にも満足できると確かめました。

これらのフィードバックには、それぞれ異なる目的があります。テストは機能の確認に役立ち、スクリーンショットはインターフェースの状態を示し、操作録画は一連のフローがどのように完了するかを示し、自分での試用は使用感を補完します。開発者は段階的な監視を減らしながらも、成果物を通じて作業の進捗状況を判断することができます。

実装が目標に適合しているかどうかは、コードレビューと実際の使用フィードバックによって確認されます。前者はコードと設計の問題を発見するのに役立ち、後者はチームがツールの導入後に何が起こったかを把握することを可能にします。

実装とフィードバックをつなぎ、製品全体を前進させる

インタビューで最も包括的なケースは、あるメンバーが複数人のサポートを必要とする社内ツールを開発した例です。彼はまず Claude に、このアイデアについて誰と議論すべきか、誰が関心を持つ可能性があるかを特定させ、次にインターフェースのプロトタイプを作成しました。人間はスマートフォンの Slack を通じてプロトタイプを確認し、具体的なプランを議論できるため、アイデアは次の実装段階に進みやすくなります。

コードが作成された後、新たな問題が浮上しました。ツールが実際に使用されているか、ユーザーがフローを完了できるかどうかです。彼はツールにイベント記録を追加し、社内展開後に Claude が使用状況を継続的に観察し、同僚のフィードバックにも注意を払うようにしました。必要に応じて、議論に参加するよう自分に通知することもします。

この製品開発の連鎖において、各ステップが次のステップへの情報を提供しています。

最後の転換が最も価値があります。開発者は、一部のユーザーが操作フロー全体を完了していないことに気づきました。彼は当初、自分の修正案を Claude に実装させようと考えていました。しかしその後、彼は質問の仕方を変えました。Claude にこのフローの改善を依頼し、まず考え方を提案してもらうことにしました。自分の案は一例として提供しました。

チームはこのプロセスを「ファネル」と呼んでいます。ユーザーが使用開始から目標達成までに経る一連のステップを指します。ユーザーがどのステップで停止したかを知ることは、分析の出発点に過ぎません。改善目標を Claude に委ねることは、Claude が現象を基に原因を探り、プランを比較できることを意味し、初めから人間が選択した答えを実行するだけではありません。

関連する同僚、プロトタイプ、実装、イベント記録、フィードバックは、これによって同じ目標に向かって結び付けられています。テストとレビューは変更のチェックに役立ち、使用フィードバックは次のラウンドの選択の根拠を提供します。Claude が関与する範囲は、コードから製品の継続的な改善へと広がり、人間はその中で方向性を決定し、重要な問題を処理し、実際の使用感を確認しています。

エンジニアもまた、自分ができることの判断を更新する

ツールが変わるにつれて、チームメンバーが自分の仕事に抱くイメージも変わってきています。以前はパフォーマンス最適化に熱中していた人や、macOS Aqua ボタンの CSS グラデーションを正確に再現するために丸一日かけたことのある人もいました。現在では、そのような具体的な実装は Claude に任せ、新しいアイデアに労力を注ぎ、プロトタイプをより迅速に実用的な製品へと近づけることを好んでいます。

あるメンバーは、子供の頃にプログラミングができなかったため、PowerPoint でゲームを作ろうとしたことを思い出しました。このエピソードは、アイデアはあるのに自分ができない技術によって妨げられるという、よく知られた制限に対応しています。Claude とのコラボレーションにより、そのようなアイデアの多くを分解し、試し、形にすることができるようになりました。人間の能力の限界についても、ツールの能力に応じて再評価する必要があります。

この経験を自分の仕事に生かすには、今取り組んでいる業務から始めるとよいでしょう。まず目標と背景を明確にし、実行環境を整えます。そのうえで Claude に作業手順の設計にも参加してもらい、どのような成果物とフィードバックを持ち帰ってもらうかを取り決めます。

これらの方法は、チームが自らの環境での実践から得たものです。具体的な設定は、各自のプロジェクトに合わせて調整する必要があります。より継続的に練習すべきは、どの作業をより完全に委任できるか、どの古いツールや習慣が再設計に値するかという、二つの判断を同時に更新することです。