チームでAnthropicを導入する際にリーダーがまず決めるべきこと

この記事は AI により作成・編集され、運営者の確認後に公開されています。サムネイルも AI 生成の場合があります。

新しいプロジェクトに加わった同僚が、レガシーモジュールのリファクタリングを担当することになりました。数千行に及ぶファイルを理解するため、Claude 3 Opusのような高性能モデルにコード全体をコピー＆ペーストして質問を始めました。結果はかなり満足のいくものでしたが、同じような作業をしていた別のチームメンバーは、異なるモデルを使ったり、異なる方法で質問したりしたため、全く異なる回答を得ました。

月末に請求書が精算され、全員が驚きました。特定のいくつかの作業で、予想よりも数十倍高い費用が発生していることが判明したのです。原因は、長いコンテキストを無分別に入力していたことでした。個人の生産性は一時的に向上したかもしれませんが、チーム全体で見ると費用予測が不可能になり、成果物の一貫性も失われるという問題が発生したのです。

この記事では、チームにAnthropicモデルを導入する際に、テクニカルリードやシニア開発者が事前に定めておくと良い、いくつかのルールと基本設定について説明します。これにより、費用を予測可能に管理し、チームメンバーの成果物の品質を一定レベルに維持するのに役立ちます。

© AI生成画像

なぜルールが必要なのか：自由と混沌の間

LLM APIをチームのワークフローに連携する際の最大の利点は、膨大な量の情報を処理できる能力です。しかし、この利点は同時に費用に直結する欠点にもなります。明確なガイドラインがなければ、各自が異なる方法でモデルを利用することになり、それが予測不可能な費用と成果物のばらつきにつながります。

最もよくある問題は、「最高性能モデル万能主義」です。特定の作業にはより軽量で高速なモデルが適しているにもかかわらず、無条件に最も高価なモデル（例：Claude 3 Opus）を選択する傾向があります。また、コンテキストをどの程度、どのように提供すべきかという基準がなく、ファイル全体を丸ごと入力する作業が繰り返されます。

したがって、チームレベルで最低限のルールを定めることは、個人の自律性を損なうためではなく、チーム全体の持続可能な活用にとって不可欠なプロセスなのです。

1. モデル選択と利用量の上限設定

すべての作業にOpusモデルが必要なわけではありません。作業の性質に応じて適切なモデルを選択するよう案内するだけで、費用を大幅に削減できます。チームで次のような簡単な基準を定めて共有することをお勧めします。

• Claude 3 Haiku: 簡単なコード形式変換、コメント生成、コミットメッセージ作成など、高速で費用効率の高い作業に適しています。
• Claude 3 Sonnet: ほとんどの開発作業（関数作成、ロジック分析、テストケース生成）に基本として利用します。性能と費用のバランスが最も優れています。
• Claude 3 Opus: 複雑なアーキテクチャ分析、大規模なレガシーコードのリファクタリング提案など、深い推論が必要で高い費用を許容できる作業に限り、チームリーダーと協議の上で活用します。

また、APIを直接呼び出すスクリプトや内部アプリケーションでは、max_tokensパラメーターを必ず設定し、予期せぬ長さの応答による費用急増を防ぐ必要があります。

import anthropic

client = anthropic.Anthropic(
    # API キーは環境変数から読み込みます。
    api_key="<YOUR_ANTHROPIC_API_KEY>",
)

# 予測可能な費用のため、max_tokens を必須で設定します。
# 一般的に 4096 程度であれば十分な応答を得られます。
MAX_TOKENS_FOR_RESPONSE = 4096

message = client.messages.create(
    model="claude-3-sonnet-20240229",
    max_tokens=MAX_TOKENS_FOR_RESPONSE, # 出力トークン制限
    messages=[
        {"role": "user", "content": "この Python 関数の時間計算量を分析して。"}
    ]
)

print(message.content)

このように、コードレベルで安全装置を設けることで、開発者のミスをシステムが補完することができます。

2. システムプロンプトの標準化

チームメンバーごとに異なるシステムプロンプトを使用すると、モデルの応答のトーン、形式、重視する視点が異なります。特にコードレビューやドキュメント生成のような定型作業では、成果物の一貫性が重要です。

チーム共通のシステムプロンプトテンプレートを作成し、これを利用するよう推奨するのが良いでしょう。例えば、コードレビュー用のシステムプロンプトは次のように作成できます。

You are an expert software developer with a focus on writing clean, maintainable, and robust code.
Your task is to review the provided code snippet.

Please follow these instructions:
1.  **Primary Goal**: Identify potential bugs, performance issues, and deviations from best practices.
2.  **Clarity**: Provide clear and concise feedback. For each point, explain *why* it's an issue and suggest a specific improvement.
3.  **Tone**: Maintain a constructive and collaborative tone. Avoid overly critical language.
4.  **Format**: Structure your feedback using markdown. Use headings for major points and bullet points for details.
5.  **Scope**: Do not comment on code style (like indentation or line length) unless it severely impacts readability. Focus on logic and structure.

このようなテンプレートをWikiやチーム共有ドキュメントに登録し、チームメンバーが各自の環境でこのプロンプトをデフォルト値として設定するよう案内すれば、成果物のばらつきを大幅に減らすことができます。

3. コンテキスト長と形式のガイドライン

最も大きな費用を発生させるコンテキスト入力を管理するための明確なルールが必要です。

• 規則 1: ファイル全体を入力しません。
  • 質問に必要な最小限の関数、クラス、またはコードブロックだけを選択して渡します。
• 規則 2: 依存関係に関する情報は要約して提供します。
  • 特定のクラスについて質問する際、そのクラスが継承する親クラスや使用する他のオブジェクトのコード全体を入れるのではなく、必要なメソッドシグネチャや属性だけを簡潔にテキストで説明します。
  • 例：「User」モデルについて質問する際、「このモデルはBaseModelを継承しており、created_atとupdated_atフィールドを持っています」と明示的に伝える方が、BaseModelのコード全体を貼り付けるよりもはるかに効率的です。
• 規則 3: 会話履歴を賢く管理します。
  • チャットインターフェースで会話を続ける際、以前の会話がすべてコンテキストに含まれ、費用が累積されます。話題が変わったり、以前の情報が不要になったりした場合は、新しい会話を開始することをルールとして定めます。

これらの規則は強制するよりも、なぜこのような規則が必要なのか（費用削減、より正確な回答の誘導）をチームメンバーに十分に説明し、共感を形成することが重要です。

結論：状況に応じたルール適用

すべてのチームに同じ規則が適用されるわけではありません。チームの規模、プロジェクトの性質、予算の大きさに応じて、適切なレベルのガイドラインを定めることが重要です。

AIモデルは強力なツールですが、費用と一貫性という明確なトレードオフが存在します。私たちのチームの状況に合った最低限のルールを定め、継続的に改善していくことで、このツールをはるかに持続可能で効果的に活用できるでしょう。

#

参考文献

• Messages API
• Prompt Engineering