以下はhttps://www.dzombak.com/blog/2025/08/getting-good-results-from-claude-code/の翻訳です。

Claude Codeから良い結果を得る

ここ数か月間、LLM（大規模言語モデル）のプログラミングエージェントを試してきました。Claude Codeは、私のお気に入りになりました。

問題がないわけではありませんが、比較的短期間で12のプログラムやプロジェクトを作成することができました。Claude Codeがなければ、同じ時間でこれらすべてをこなすことはできなかったでしょう。ほとんどのプロジェクトは、単に時間がかかりすぎるという理由で、Claude Codeなしでは書く気にならなかったと思います。（記事の最後にリストが含まれています。）

私はまだClaude Codeの専門家にはほど遠く、役立つかもしれないブログ記事やドキュメントが山ほどあります。しかし、重要なのは、結果を出すために世に出ているすべてのものを読む必要はないということです。この投稿を読む必要さえありません。ただプロンプトを入力してみて、何が出てくるか見てみればいいのです。

とはいえ、たまたま仕事の応募のためにこの文章を書いたので、私がClaude Codeから良い結果を得る方法をここに紹介します。適切な箇所にいくつかの例へのリンクを追加しました。

鍵となるのは、作業に入る前に明確な仕様書を書くことです。これにより、エージェントはコードベースで作業する際のコンテキスト（文脈）を得ることができます。（例：1, 2, 3, 4）

プロジェクトの構造や、ビルドやリンターの実行方法などをまとめたドキュメントをエージェントに提供することも役立ちます。（例：1, 2, 3）

エージェント自身のコードレビューを依頼することは、驚くほど効果的です。

最後に、私はエージェントが従うべきベストプラクティスを記述した個人的な「グローバル」エージェントガイドを持っています。これには、問題解決のアプローチやTDD（テスト駆動開発）の使用法などが指定されています。（このファイルは、この記事の最後のほうに記載されています。）

次に、LLMが書いたコードを検証するという問題があります。

AIが生成したコードは、しばしば不正確であったり非効率的であったりします。

私の名前が載ったPR（プルリクエスト）に入るコードについては、それがどのように生成されたかに関わらず、最終的な責任は私にあると信じていることを強調することが重要です。

したがって、特にプロフェッショナルな環境では、AIが書いたすべてのコードとテストケースを手動でレビューします。欠けていると思うものや改善が必要なものがあれば、手動で、またはLLMにそれらのケースを書くように依頼して（その後レビューします）、テストケースを追加します。

結局のところ、動作が正しく実装され、適切にテストされていることを確認するには、手動レビューが必要です。

Development Guidelines

Philosophy

Core Beliefs

Incremental progress over big bangs – Small changes that compile and pass tests
Learning from existing code – Study and plan before implementing
Pragmatic over dogmatic – Adapt to project reality
Clear intent over clever code – Be boring and obvious

Simplicity Means

Single responsibility per function/class
Avoid premature abstractions
No clever tricks – choose the boring solution
If you need to explain it, it’s too complex

Process

1. Planning & Staging

Break complex work into 3-5 stages. Document in IMPLEMENTATION_PLAN.md:

## Stage N: [Name]
**Goal**: [Specific deliverable]
**Success Criteria**: [Testable outcomes]
**Tests**: [Specific test cases]
**Status**: [Not Started|In Progress|Complete]

Update status as you progress
Remove file when all stages are done

2. Implementation Flow

Understand – Study existing patterns in codebase
Test – Write test first (red)
Implement – Minimal code to pass (green)
Refactor – Clean up with tests passing
Commit – With clear message linking to plan

3. When Stuck (After 3 Attempts)

CRITICAL: Maximum 3 attempts per issue, then STOP.

Document what failed:

What you tried
Specific error messages
Why you think it failed

Research alternatives:

Find 2-3 similar implementations
Note different approaches used

Question fundamentals:

Is this the right abstraction level?
Can this be split into smaller problems?
Is there a simpler approach entirely?

Try different angle:

Different library/framework feature?
Different architectural pattern?
Remove abstraction instead of adding?

Technical Standards

Architecture Principles

Composition over inheritance – Use dependency injection
Interfaces over singletons – Enable testing and flexibility
Explicit over implicit – Clear data flow and dependencies
Test-driven when possible – Never disable tests, fix them

Code Quality

Every commit must:
Compile successfully
Pass all existing tests
Include tests for new functionality
Follow project formatting/linting
Before committing:
Run formatters/linters
Self-review changes
Ensure commit message explains “why”

Error Handling

Fail fast with descriptive messages
Include context for debugging
Handle errors at appropriate level
Never silently swallow exceptions

Decision Framework

When multiple valid approaches exist, choose based on:

Testability – Can I easily test this?
Readability – Will someone understand this in 6 months?
Consistency – Does this match project patterns?
Simplicity – Is this the simplest solution that works?
Reversibility – How hard to change later?

Project Integration

Learning the Codebase

Find 3 similar features/components
Identify common patterns and conventions
Use same libraries/utilities when possible
Follow existing test patterns

Tooling

Use project’s existing build system
Use project’s test framework
Use project’s formatter/linter settings
Don’t introduce new tools without strong justification

Quality Gates

Definition of Done

[ ] Tests written and passing
[ ] Code follows project conventions
[ ] No linter/formatter warnings
[ ] Commit messages are clear
[ ] Implementation matches plan
[ ] No TODOs without issue numbers

Test Guidelines

Test behavior, not implementation
One assertion per test when possible
Clear test names describing scenario
Use existing test utilities/helpers
Tests should be deterministic

Important Reminders

NEVER:

Use --no-verify to bypass commit hooks
Disable tests instead of fixing them
Commit code that doesn’t compile
Make assumptions – verify with existing code

ALWAYS:

Commit working code incrementally
Update plan documentation as you go
Learn from existing implementations
Stop after 3 failed attempts and reassess

免責事項

記事は、一般的な情報提供のみを目的としてのみ作成したものであり、投資家に対する有価証券の売買の推奨や勧誘を目的としたものではありません。また、記事は信頼できると判断した資料およびデータ等により作成しておりますが、その正確性および完全性について保証するものではありません。また、将来の投資成果や市場環境も保証されません。最終的な投資決定は、投資家ご自身の判断でなされますようお願いします。

Claude Codeから良い結果を得る(Getting Good Results from Claude Code)