Flask作者 Armin Ronacher の Claude Code 活用法【具体例つき】

Armin Ronacher 氏は、Claude Code（Claude CLI）を「速いが指示に忠実なジュニアエンジニア」として扱い、環境そのものをエージェントの作業ループに最適化することで知られます。本記事では、氏のブログから具体例を引用しながらその実践を掘り下げます。

本記事は、Armin Ronacher 氏のブログ記事を当社が調査し日本語でまとめたものです。引用は元記事からの抜粋で、出典は記事末尾に記載しています。原文の正確なニュアンスは必ず元記事でご確認ください。

1. 構成は「安く・隔離して全開」

まず驚くのがコスト感です。氏は高価な Opus ではなく、月額100ドルの Max プランで Sonnet モデルだけを使うと明言しています。

I predominently use Claude Code with the cheaper Max subscription for $100 a month. I exclusively use the cheaper Sonnet model.

— Agentic Coding Recommendations (2025-06-12)

そして権限確認を完全にスキップするclaude-yolo エイリアス（中身は claude --dangerously-skip-permissions）を使い、その危険性をDocker による環境隔離で打ち消します。「全開で走らせる代わりに、壊れても影響が閉じる箱の中で動かす」という発想です。

# 権限プロンプトを一切出さずに全開で走らせる（中身のイメージ）
alias claude-yolo='claude --dangerously-skip-permissions'

# ただし開発環境ごと Docker の中に閉じ込めて事故を封じる

2. エージェントが「自己診断」できるログ運用

氏の工夫で特に実用的なのが、すべての出力をファイルにも記録すること。これによりエージェントがログを読み返して自分で原因を突き止められます。

I am not only printing the output to my terminal, I'm also always logging it to a file.

— Agentic Coding Recommendations (2025-06-12)

具体的には make dev でサービス群を起動し、make tail-log でログを追えるようにしておきます。プロセスマネージャは shoreman のフォークを使い、pidfile を書いて二重起動を防止。さらにサインイン用のメール（確認リンク）もログに出すことで、エージェントが自力で認証フローを完了できるようにし、その手順は CLAUDE.md に書いておく、という徹底ぶりです。

# タイムスタンプ付きでファイルにも残るので、エージェントが読んで自己診断できる
make dev        # プロセスマネージャ経由でサービス起動（出力はファイルへも）
make tail-log   # 直近ログを確認

3. 「LLM が読みやすいコード」を書く

氏の最も特徴的な主張が、エージェントが理解しやすいことを最優先にコードを設計するという姿勢です。ブログでは具体的なルールが挙げられています（いずれも逐語引用）。

Prefer functions with clear, descriptive and longer than usual function names over classes.

Avoid inheritance and overly clever hacks.

Use plain SQL. I mean it.

Keep important checks local.

— Agentic Coding Recommendations (2025-06-12)

• クラスより、長めで説明的な関数名 — 人間にもエージェントにも grep で見つけやすい
• 継承や過度に賢いハックを避ける
• 「プレーンな SQL を使え。本気で言っている」 — ORM より、エージェントが書く素の SQL の品質を信頼
• 重要なチェックはローカルに置く — 権限・セキュリティ確認を、関係する箇所のすぐ近くに見える形で

言語選択にも同じ論理が貫かれます。氏はバックエンドに Go を好み、その理由として「明示的な context.Context」「テスト結果がキャッシュされ反復ループが効率的」「構造的インターフェースで LLM が解釈しやすい」「後方互換性が高くエコシステムの変化が少ない」を挙げます。そして2026年には、同じ理由からPython より TypeScriptへ手を伸ばすようになったと述べています。

I'm now routinely reaching for JavaScript in places where I would have used Python. Not because I love it or the ecosystem is better, but because the agent does much better with TypeScript.

— A Language For Agents (2026-02-09)

4. 「MCP より コード（CLI）」という持論

氏は MCP（Model Context Protocol）サーバーに懐疑的で、エージェントにはツールを呼ばせるよりコードを書かせて実行させるべきだと主張します。読者に勧める検証はこうです。

Try completing a GitHub task with the GitHub MCP, then repeat it with the gh CLI tool. You'll almost certainly find the latter uses context far more efficiently.

— Tools: Code Is All You Need (2025-07-03)

多数の専用ツールはコンテキストを圧迫します。氏の言葉では 「ツールが増えるほど、コンテキストの腐敗（context rot）に加担することになる」。代わりに、状態を保持する単一の「ubertool」（実質 Python インタプリタ）に向かってプログラムさせるほうが、合成可能で効率的だと説きます。古い格言「自分をシェルスクリプトで置き換えろ」を、LLM 生成コードへの委譲に拡張した形です。

5. 「うまくいかなかった」ことも公開する

氏は成功例だけでなく効果がなかった手法も率直に記録しています（"Things that didn't work"）。これは実務者にとって非常に参考になります。

• カスタムスラッシュコマンド（/fix-bug、/commit、/add-tests など）— 「結局 Issue の URL を貼るのと変わらない」「自分のスタイルに合わない」と定着せず
• Hook — 「頑張って使おうとしたが、効率の向上が見られなかった」。代わりに PATH インターセプターでツール選択を誘導
• Print モード（-p） — 概念は良いが「遅くてデバッグしにくい」
• サブエージェント — 新しいセッションを始めたり、考えを Markdown に書き出すほうが良い結果になることが多かった

つまり「ベストプラクティスとされる機能が、必ずしも自分のワークフローに効くとは限らない」ことを、実験で見極めている点が氏の流儀です。なお2025年末には、Cursor 中心の作業からほぼハンズオフの Claude Code 中心へ移行したと述べ、自らを「キーボードを叩く側より、仮想的なプログラマーインターンを率いるエンジニアリードでいたい」と表現しています。