🛠️ Claude Code は実際どう使われているか — 実在確認した30の使い方

この記事は「Claude Codeでこんなことができます」という機能紹介ではない。実在が確認できた使用例だけを、誰が・何のために・どういう仕組みで・結果どうなったかで集めたカタログである。

企業事例はAnthropic公式ブログと各社（CyberAgent・DeNA・freee・LayerX・Mercari）のエンジニアリングブログから。個人の実装はGitHubのリポジトリをAPIで直接叩いて実在確認したものだけを載せている。発明したリポジトリ名・企業名・数値は一つもない。

研究者Kevin Yangは、直近の学術論文でコードの98%以上をClaude Codeが生成したと自身のSubstackで明言している。ワークフローは5段階に分かれる。まずプロジェクト全体の計画を、データクレンジング・複数の研究課題ごとの分析・出力生成に分割する。次に各スクリプトを逐次生成し、各ステップの後に必ずレビューと検証を挟む。バージョン管理はGitとLazygitで行い、いつでもロールバックできる状態を保つ。データはParquetファイルで保存し、parquet-toolsコマンドで中身を検査する。

入力は生データ（CSV等）と分析方針、出力は検証済みの分析スクリプト・Parquet中間ファイル・最終的な論文用の図表とコードである。セットアップはiPadでClaude Codeを「第三の画面」として使い、Cursorでレビューと軽微な編集、Jupyter Notebookで探索を行う。本人は「もう手作業のコーディングには戻らない」と述べ、成功の鍵は事前の計画立案とコンテキストウィンドウの能動的管理にあるとしている。

個人開発者Kevin Kinnettは、収入・支出・予算・純資産・投資・負債・キャッシュフロー予測・請求書管理までを含む家計管理アプリを、React 19・Node.js 22・PostgreSQL・Docker・Windmill（スケジュールジョブ）・Tailscale（安全なリモートアクセス）で構築した。規模はTypeScript約45,000行・27ページ・30 APIルート・40以上のDBテーブル。初コミットから動く状態まで12日・132コミットだった。

入力はアプリの要件と各機能の仕様、出力はDBマイグレーション・APIルートの雛形・UIコンポーネント・CRUD操作の反復部分のコードである。アーキテクチャ判断・機能の優先順位・設計方針は本人が保持し続けた。本人の言葉を借りれば「Claude Codeが変えたのは速度であって、責任ではない」。機密性の高い財務データを扱うため、意図的にセルフホストを選んでいる。

KDDIアジャイル開発センター所属のみのるん氏は、業務でAIエージェント開発を行う一方、個人の日常業務にもClaude Codeを常用している。家計簿はマネーフォワードのCSVエクスポートをClaude Codeに読み込ませて分析する運用に置き換え、月次支出分類・前年同月比・長期資産シミュレーション・退職後シミュレーションまで行う。業務側では、Gmailの領収書メールとクレジットカード明細を突合させて経費精算を自動化し、所要時間を30分から5〜10分に短縮した。月次出社日数の自動カウント、プロジェクト別に分類した工数レポートの作成、登壇依頼メールからのスプレッドシート抽出も行い、EventBridgeとBedrockを組み合わせたサーバーレス構成でGmailのスター付きメールを1日3回チェックしてSlack通知する仕組みも構築した。

入力はCSV・領収書メール・カード明細・カレンダー・登壇依頼メールといった業務データ、出力は家計/経費レポート・工数レポート・Slack通知である。運用の基盤としてPLAN.md（音声入力の脳内ダンプ）・SPEC.md（対話で仕様を固める）・TODO.md（セッションをまたぐタスク管理）・KNOWLEDGE.md（再発防止の知見蓄積）の4ファイルを使い分け、複数ターミナルでClaude Codeを並列起動している。

個人開発者の@tobaru-hideyasu氏は、Obsidianに書いた日記をGitHubのプライベートリポジトリに同期し、8つのカスタムスキルで運用している。/taskスキルは「2月の日記をスキャンして実行可能な項目をGitHub Issue化して」という指示で、1ヶ月分の散在した日記から約50件のタスクを抽出し、重複除去と関連グループ化を経て46件のIssueに優先度P0〜P3・領域タグ・種別タグを付与した。/weekly-reviewは7日分の日記を仕事・開発・家族・健康等の観点で要約するが、AIの言い換えを避け原文の言葉を保持する方針を貫く。

入力は日記本文（Obsidian経由）、出力はGitHub Issue・週次レビュー・ニュース収集結果である。加えて/coach（朝の対話で健康シグナルを検知し軌道修正を促す）・/reflect（本人の言葉を引用して感情パターンを指摘する）・/sparring（3つの視点でアイデアを批判的に検証する）という3つの対話パートナー型スキルも定義している。結果として3本の週次レビュー・70件のニュース収集・2本のGitHub Actionsが自律稼働するようになった。

DeNAでは、プロダクトマネージャー（PdM）がミーティングメモやSlackの議論からNotionのPRD（製品要件文書）を自動更新し、GitHubチケットも自動生成する運用に切り替えた。デザイナーはラフ仕様からUI/UXモックを作成し、Figmaのデザインデータ（オートレイアウト適用済み）に変換、静的なデザインでなくインタラクティブなプロトタイプをエンジニアと共有して「実装可能か」を直接相談できるようになった。結果、仕様確定から動くプロトタイプまでのサイクルが2〜4週間から1〜2日に短縮された。週1回、職種をまたいでAI活用の成果や試行錯誤を共有する場も設けている。

加えてDeNAは、セッションログや~/.claude配下のメモリファイルが自動蓄積されても誰も見返さないという課題に対し、その中身（KPI・日次活動量・プロジェクト分布）を可視化し、CLAUDE.mdの改善案やセッションパターンから再利用可能な「自己知識スキル」を自動生成する社内アプリ「geniハーネスくん」を内製した。個人情報を除去したハーネスをチームメンバー間で共有できる仕組みで、暗黙知が異動や離職で失われるリスクに対処している。

まずCLAUDE.mdとの違いを分けておく。CLAUDE.mdは、システムプロンプトの後にユーザーメッセージとして追加される指示ファイルだ。対してOutput Stylesはシステムプロンプトそのものを書き換える。同じ「振る舞いを変える」設定に見えても、置かれている層が違う。

この違いは、既存の開発規約へ補足を足すのか、Claude Codeの説明のしかたや役割そのものを変えるのか、という使い分けになる。公式ドキュメントでは独自スタイルを.claude/output-styles/にMarkdownで置けるとしている。出典: https://code.claude.com/docs/en/output-styles

組み込みのProactiveは確認を重ねずに作業を進める。Explanatoryは、なぜその実装判断をしたかを教育的に説明する。LearningはTODO(human)という印を残し、人間が実装する部分を意図的につくる協働モードである。単に返答の口調を変えるだけではなく、作業を誰がどこまで担うかにも手を入れる。

さらにkeep-coding-instructionsを外すと、コーディング向けの指示を保たないスタイルにできる。公式資料では、ライティングアシスタントやデータアナリストのような、非エンジニアリング用途の人格に切り替える例が示されている。

hesreallyhim/awesome-claude-code-output-styles-that-i-really-likeには、Output Stylesの説明自体を異なる語り口で伝える3つの実例がある。tabloid-journalist.mdはタブロイド紙の煽り見出し調、zen-master.mdは禅僧の一人称、technical-evangelist.mdは標準的な技術解説調で書かれている。

ここで重要なのは、3つが別々の機能を説明しているのではないことだ。技術的な正確性を保ったまま、同じ内容を伝え方だけ変えるデモになっている。Output Stylesが追加の指示ではなく、エージェントの人格そのものを差し替える別レイヤーだという点が、この並びではっきりする。出典: https://github.com/hesreallyhim/awesome-claude-code-output-styles-that-i-really-like

AGENTS.mdは、エージェントにリポジトリ固有の仕事のしかたを渡すMarkdownファイルである。OpenAI Codex、Amp、Google Jules、Cursor、Factoryなど複数のツールベンダーの協業から生まれ、現在はLinux Foundation傘下のAgentic AI Foundationがスチュワードシップを持つ。任意の見出し構成で書けるため、実物の差は単なる行数よりも、何をエージェントの行動規則として置くかに表れる。出典: https://agents.md/

openai/codexの322行のAGENTS.mdは、Rustワークスペースのcodex-rs部分に向けた指示である。珍しいのは、CODEX_SANDBOX_NETWORK_DISABLED_ENV_VARとCODEX_SANDBOX_ENV_VARを絶対に変更しないよう命じている点だ。この指示を読むのが、まさにそのサンドボックス内で動くCodex自身であることを前提にした、自己言及的な書き方になっている。

また、特定のclippy lintへの準拠と、位置引数のリテラルに/*param_name=*/コメントを付ける独自lint argument_comment_lintも置かれている。一般的な規約だけでなく、このリポジトリ固有の検査まで渡している例である。出典: https://github.com/openai/codex

sveltejs/svelteのAGENTS.mdは11行と短い。本体の指示は.claude/skills/ではなく、ツールに依存しない.agents/skills/performance-investigation/にある。AGENTS.mdには、パフォーマンス調査を頼まれたらperformance-investigationスキルを使う、という参照を1行で置き、詳細は別ファイルに任せている。

短いのは、指示が少ないからではない。入口だけをAGENTS.mdに残し、詳しい手順を外へ分けているためである。出典: https://github.com/sveltejs/svelte

temporalio/temporalの104行は、冒頭から2人称でエージェントへペルソナを与える。「あなたはtemporalプロジェクトで働く経験豊富な開発者であり、分散システム、データベースエンジン、スケーラブルなプラットフォームを背景に持つ」という書き出しだ。

続くCore Mandatesでは、ライブラリの存在を決めつけずにgo.modを確認するよう求める。手順だけでなく、調査するときの立場と慎重さを先に指定している。出典: https://github.com/temporalio/temporal

block/gooseの121行は、コーディング規約ではなくIssue管理ワークフローをAGENTS.mdへ埋め込んでいる。PRの前に対応IssueがReady状態か確認し、Inbox、Needs info、Accepted / designのIssueは実装せず、まず議論の解決を優先する。

GitHub Projectsボードの状態遷移を、エージェントが実装に入る条件として明文化している。コードを書く前の仕事の流れまで、行動規則に含める例である。出典: https://github.com/block/goose

複数のエージェントツールを併用する場合、同じ指示を二重に保つ必要はない。個人開発者tatsukiは、AGENTS.mdをCLAUDE.mdへのシンボリックリンクにし、Claude CodeとCodex CLIが同じ指示ファイルを読む構成にしている。出典: https://note.com/nobel/n/nb87d014c8a8a

この記事のためにGitHub検索 q=codex+cli を回すと、上位に星の数が異常なリポジトリが並ぶ。ここではその実例と、疑う根拠、読者自身が判定するためのチェック手順をまとめる。星の水増しを断定する記事ではない。断定できる証拠は今回の調査では取得できなかった。

1日800★超というペースは、真に爆発的に伸びたOSSプロジェクトでも稀である。3件とも、GitHub検索で「Claude Code」「Codex」関連のキーワードを入れた時に上位に出てくる点が共通している。

この系統のリポジトリに共通するのが、説明文（description）の書き方である。「Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Antigravity...」のように、話題のAIコーディングツール名を判で押したように羅列する。1つのツールに絞った具体的な説明ではなく、検索でヒットしやすいキーワードを並べているように読める。

この記事の他の章で引用してきた hesreallyhim/awesome-claude-code のような人力キュレーションリストは、「originality（独自性）を重視し、マーケティング目的の掲載を排除する」という方針を掲げている。星数だけを基準にリポジトリを評価すると、この章で見たような水増しの疑いが強い案件を拾ってしまう。人が中身を読んで選ぶキュレーションは、その汚染に対する防波堤として機能している。

ここまで、フックの珍しい使い方から星の水増しの疑いまで、実在確認したものだけを見てきた。最後に、読者が明日から動けるように、導入コストが低い順に並べ直す。設定ファイルだけで終わるものから、リスクの理解が要るものまで段階が分かれている。

実在確認できたものだけを書く、という方針で進めてきたが、以下は方向性だけ確認でき、詳細や一次ソースまでは今回の調査時間内で特定できなかった。