powered by TechFeed
表示モード
ハウツー

Claude Codeを使いこなす4つの実践テクニック — 「即実装させない」「声で入力する」がエージェント活用の鍵になる

7月27日、Eivind Kjosbakkenが「How to Efficiently Prompt Claude Code」と題した記事を公開した。AIコーディングエージェントを「走らせる」だけでなく「使いこなす」ために何が必要か——その問いに対し、Kjosbakkenは「言葉のチューニングより協業設計」という実践的な視点から4つの手法を提示している。

7月27日、Eivind Kjosbakkenが「How to Efficiently Prompt Claude Code」と題した記事を公開した。AIコーディングエージェントを「走らせる」だけでなく「使いこなす」ために何が必要か——その問いに対し、Kjosbakkenは「言葉のチューニングより協業設計」という実践的な視点から4つの手法を提示している。


Claude CodeはAnthropicが提供するAIコーディングエージェントで、エンジニアのコード生成・デバッグ・実装タスクを自律的にこなすツールだ。近年、同種のエージェント型ツール(OpenAIのCodex CLIなど)が急速に普及しており、「どう使いこなすか」が実務上の関心事になっている。

Kjosbakkenは冒頭で重要な前提を指摘する。数年前のLLMは、プロンプトの文言順序や末尾の一文を変えるだけで出力が大きく変わっていた。しかし現在のモデルはそうした些細な差異に左右されなくなった。プロンプティングの本質は「言葉のチューニング」から「エージェントとの協業設計」へとシフトした、というのが彼の主張だ。

最も効いた技術:「声で入力する」

記事で最も実用的なTIPSが、音声入力(トランスクリプション)の活用だ。Kjosbakkenはローカルで無料動作するトランスクリプションツールを使い、プロンプトを音声で入力している。

※元記事で言及されているツール名については、正確なURLの確認が取れなかったため本記事ではリンクを省略している。

話すスピードはタイピングの平均2〜3倍とされており、単純な時短効果だけではない。彼が強調するのは「コンテキストの充実度」だ。

手で打っていた頃は、コンテキストをすべて書き出すのが面倒で省略することがあった。それはエージェントのパフォーマンスを確実に下げていた。音声入力に変えてから、必要な背景情報を惜しみなく渡せるようになった。

Claude Codeに限らず、コーディングエージェント全般に言えることだが、コンテキスト不足はタスク失敗の最大の原因だ。音声入力はその障壁を物理的に下げる手段として機能する。

実装前に「議論」する

次に重要なのが、「即実装させない」という考え方だ。

多くのエンジニアはプロンプトを投げてエージェントを走らせる。しかしKjosbakkenは、実装に着手させる前に必ず議論フェーズを設ける。コードベース全体を把握した上で、エージェントに以下を求める。

  • 関連ログやコードを調査させる
  • 必要なら関連情報をウェブ検索させる
  • 実装上の曖昧な点をすべて質問させる
  • 大きな設計判断(例:AWSのインフラをCLIで直接構築するかCDKとしてコードで定義するか)を事前に明示させる

人間はコードベースの全コンテキストをワーキングメモリに保持できない。一方でエージェントはそれが可能だ。だからこそ、エージェントを「実行者」ではなく「議論相手」として使うことで、後から手戻りが発生するリスクを大幅に下げられる。

テスト方法をプロンプトに含める

これも実践的な指摘だ。機能の実装を依頼するとき、「どうテストすればよいかも一緒に指示する」

例えばチャット機能を実装させる場合、「Chromeでチャットを開いて、クエリを自分で入力して、AIが正しく応答しトークンがストリームされることを確認せよ」という検証手順までプロンプトに盛り込む。

この手法が有効な理由は、エージェントの「完了」の定義を明示的に揃えることにある。検証基準を与えなければ、エージェントはコードが動く状態を「完成」と判断しがちだ。しかし人間が期待する「完成」は、実際のユースケースで正しく動くことだ。テスト手順をプロンプトに含めることで、両者の完了基準を一致させ、手戻りを防ぐ。

HTMLレポートで確認作業を効率化

最後のTIPSがHTMLレポートの活用だ。ターミナルに大量に流れるエージェントのログは、人間が読むには冗長すぎる。そこでKjosbakkenは、意思決定や確認が必要な場面でエージェントにHTMLレポートを生成させる。

この手法が機能する理由は、エージェントとの「確認インターフェース」を構造化できる点にある。ターミナル出力をスクロールして読み解くよりも、目的に応じて設計されたHTMLページを見る方が、人間側の認知負荷が大幅に下がる。

設計上の判断を求める場面では、各決定事項について「選択肢」「概要」「メリット・デメリット」「選択ボタン」をHTMLに含めさせる。テスト確認の場面では、「テスト対象箇所」「プロダクト内の直リンク」「承認/差し戻しボタン」「フィードバック入力欄」「コピーボタン」を含めたレポートを生成させ、そのまま出力をClaude Codeにペーストして次の作業に進む、というループを構築している。

フローチャートやSVGなどビジュアルも埋め込めるため、複雑な設計判断の把握にも有効だ。


Kjosbakkenは「この手法も1〜2年後には陳腐化する可能性が高い」と率直に認めており、モデルの進化に合わせて都度アップデートしていく方針を示している。現時点でのベストプラクティスとして、上記の4つの手法は今すぐ試せる内容だ。

詳細はHow to Efficiently Prompt Claude Codeを参照していただきたい。