Claude Codeの活用事例

個人開発のプロジェクトが4〜5件同時に走り、実装よりも「今週どれを進めるか」を決める時間が膨らんでいた。

判断が溜まり続けて、放置される案件も出ていた。

1. オーナーは自分だと伝え役割別エージェント作成をClaude Codeに依頼する
2. 返ってきた質問に答えて自律の範囲とモデル配分を決める
3. 承認をDiscordとPCの両方から行えるか確認し計画を一度差し戻す
4. 9役割を定義し自動可と承認要の一覧表をCLAUDE.mdへ固定する
5. 決裁は1件1枚のMarkdownカードにしてディレクトリ移動で状態を表す

サブエージェント9体とスラッシュコマンド、初回会議の成果物まで含む骨組みが59ファイルの1コミットで立ち上がった。

スラッシュコマンドは最終的に7個になり、今はこの仕組みの下で大小10個前後の事業が動いていて、決裁待ちはコマンド1つで一覧できるようになった。

買い替えたSnapdragon X2 Elite搭載のWindowsノートPCでローカルLLMを動かしたかったが、どの実行経路とモデルが使えるかを一つずつ試すのは手間が大きかった。

1. Claude CodeをPCに入れる
2. NPUでLLMを動かす経路の調査とベンチマークをAIに任せる
3. 1モデル1プロセスで温度やseedを同じにそろえて計測する
4. 短文タスクと論文全文の査読メモ作成を走らせる
5. 速度とロード時間とRAM増加量を記録し翻訳品質は自分で確認する

NPUを全層使うqairt経路ではQwen3 4B Instruct 2507が37.1tok/sで動き、英→日1,229字の翻訳が10.4秒で終わった。

コンテキスト長4096固定という制限はあるが、翻訳や要約なら実用になると分かった。

ブログ記事の執筆やSNS投稿、転載の配信といった毎日発生する定型作業が多く、一人では量をさばききれなかった。

AIに任せても完了報告が正しいか分からず、外部への配信が止まる事故も起きていた。

1. CLAUDE.mdに破ってはいけない線を6項目だけ書く
2. main直pushの禁止と秘密情報の置き場所を明記する
3. WordPressは人がGOを出すまで下書き止まりにする
4. 品質チェックの配点や仮説の観点をSkillに固定する
5. 完了報告はgit statusとdiffの実出力を貼らせ再実行で照合する

約1か月の運用でマージしたPRは254本、書き上げた原稿は110本に達した。

Skillは10個、GitHub Actionsのワークフローは15本まで増え、外に出たものはすべて本人がGOを出したものだけで秘密情報の漏れは起きなかった。

夫婦生活費と子ども費とその他という独自の3分類が必要で、既存の家計簿アプリのカテゴリでは合わなかった。

そのため買ったものを一つずつレシートから拾って電卓で足す手作業が家庭内で続いていた。

1. 仕様の原典になる文書の構成をAIと決める
2. 作りたいものを音声入力で話し質問に答える
3. 文書間の食い違い10件を検証役が直す
4. データモデルと分類ルールと認証の3節を読み保留4件を決める
5. テスト駆動で4回に分けて実装させる

自分が手を動かした時間は2〜3時間で、コードは1行も書かなかった。

AIが書いたテストは330本で、テストを通ったあとに見つかったバグは1件だった。

家庭内の電卓での集計もなくなった。

Claude Codeが使うトークンの約9割が、込み入った推論ではなくファイルの読み込みや定型コードの出力に消えていた。

高価なモデルに単純作業まで任せる状態が続いていた。

1. 読む担当bulk-readerと書く担当code-writerの2モードを作る
2. 作業用モデルにGemini 2.5 Flashを割り当てる
3. bulk-readerで大きなファイルを読み要約だけをClaudeへ返す
4. code-writerは参考ファイル指定を必須にしひな型を出力させる
5. shuntのPreToolUseフックで350行超の読み込みを止める

Javaのモノレポで4種類の場面を試したところ、bulk-readerを通したケースでClaude側のトークン消費が平均で約90%減った。

一方で軽量モデルはスレッドセーフティーに関わる問題を見落とすことがあった。

2人で予定を共有するために自作したカレンダーアプリに写真アルバムを足したかったが、既存の予定データを壊す不安があった。

着手前に本番のFirestoreルールを見ると誰でも読み書きできる状態だった。

1. Claude Codeに「既存データは壊さず追加のみ」と条件を渡す
2. Firebase MCPで本番ルールを取り出し差分を確認して書き換えた
3. メール確認済み判定をUID判定へ人が切り替えた
4. エミュレータでテスト後にデプロイし本番と一致を確認した
5. CORSが必要という説明は実測させて誤りを訂正させた

実働は約6時間40分で23commits、55ファイル、+5,303/−416行まで進んだ。

セキュリティルールのテスト28件とCloud Functions12個を用意し、写真・動画のアルバムやLINE共有まで動かせた。

コード量を54%減らせるとうたうプラグインの数字が、自分の環境でも同じように出るか分からなかった。

モデルごとの向き不向きも判断できなかった。

1. Express製55行のTODO APIに日本語4行のチケットを7本用意する
2. headlessのclaude -pにチケットを渡し実行する
3. --plugin-dirで足す条件と足さない条件を作る
4. Haiku・Sonnet・Opusの3モデルで合計42セルを回す
5. 差分を同じprettier設定で整形し直してから数え直す

削減率は9〜25%にとどまり、54%は再現しなかった。

コストが下がったのはOpusだけで、Haikuは1件テストを落とした。

自作のタスク管理CLIのバグ修正をClaude Codeに任せていたが、1件直すたびに新しいバグ報告が生まれる感覚が続いた。

AIが自分の仕事を残すためにIssueを作っているのではないかと疑った。

1. 引数処理のバグのIssueを5パートに分けて順に修正させる
2. レビュー時に同じ構造が他に無いか横断で調べさせる
3. 見つかった箇所を新しいIssueとして起票させる
4. 1日分の起票数とクローズ数を手で数え8日分に広げる
5. nextの箱に積むかは人が決める運用に固定する

テストは1,747件から1,914件に増えた。

8日間の収支は起票7件・クローズ14件で、somedayの箱は77件から71件に減り、増加傾向には転じなかった。

原因はAIではなく網羅を求める指示の書き方だと分かった。

定期で走るはずの処理が3日間止まっていたのに誰も気づかなかった。

エラーが出ないまま止まるので、毎日見ていても異常が異常として現れなかった。

1. Claude Codeのセッションを役割で分け統括の下に実作業を並べた
2. セッション間はinbox配下のマークダウンで連絡し人間は統括だけに話す
3. 点検用のルールベーススクリプトを朝夜に走らせた
4. 閉じ忘れや返事なしなどを数え3段で判定しJSONLに残した
5. 定期ジョブが消えるためスケジューラをOS側のlaunchdへ出した

77日の運用で自動巡回は120回走り、異常なしで終わったのは9回（7.5%）だった。

検出311件のうち例外を投げたものは1件だけで、その1件も巡回スクリプト自身の通信エラーだった。

実装が終わった後に別モデルへレビューさせる流れが一般的だが、手戻りが大きいのはコードの欠陥より計画の欠陥だった。

サブゴールの切り方や依存関係の矛盾は、下流でいくら磨いても直らない。

1. 計画立案とコードレビューをClaude Codeに固定する
2. 計画の穴探しと実装をCodex側に固定する
3. 起動時にインタビューでゴールと非ゴールと受入条件を文書化する
4. JSON Schemaに沿ったverdictで計画を検証し最大3回まわす
5. 検証は読み取り専用にしてコミットは人間が行う

品質のチェックを実装後ではなく計画段階に移し、重大な指摘がゼロになってから実装へ進む流れになった。

判定の根拠がファイルに構造化されて残るため、後から見返すこともできるようになった。

詰まったところだけ質問する使い方では判断を全部自分が抱えることになり、開発の速さは1.3倍ほどで止まっていた。

ファイル編集のたびに許可を求められて作業が数分おきに止まっていた。

1. 最初にAIへ権限の表を渡した
2. 機能の順番を決める設計だけ人が確認する形にした
3. ファイル編集やマイグレーション、gitコミットは確認なしで進めさせた
4. 外部サービスへの実アクセスは目的を一言伝えさせPCやお金の操作は対象外にした
5. 報告は1時間に1回にまとめ変更ファイル名と設計理由を残させた

社内の顧客管理システムを約6週間で作り、PHPファイル74本、約3,500行のコードはほぼ全てClaude Codeが書いた。

開発に使う時間は1日15〜30分になった。

アプリ開発は素人で、Androidのカメラアプリを一人で作り切る時間も経験も足りなかった。

チャットで相談する形だと実機での動作確認まで手が回らなかった。

1. エージェント型のClaude CodeとCodexを併用しQwenも追加した
2. AGENTS.mdに全AI共通のルールを置き実測か未検証を明示させた
3. 実機投入時はAPKと端末のSHA-256一致まで確認させた
4. hookでadb uninstall等の危険なコマンドを機械的に止めた
5. 課題は自己完結HTMLのWBSで管理し実機5台で目視確認した

2026年7月23日から約50日でGoogle Playのクローズドテストまで到達した。

API従量課金なら約60万円分に当たる使用量を、月額プランの枠内で実費約1.5万円に収めた。

1人で回すWeb制作会社では、顧客管理や請求まわりの社内システムを自力で作る時間が足りなかった。

店舗向けサイトの雛形づくりにも手が回らなかった。

1. Claude Codeを開発担当の社員のように位置づける
2. 作るものの設計を先に固めて合意してからコードを書かせる
3. 指示の粒度を調整しLaravel12のモジュール構成に沿わせる
4. Stripe Cashierなど詰まりやすい箇所は自分で確認して直す
5. 完成したものをさくらのレンタルサーバーに載せて運用する

顧客管理とStripe請求、Instagram連携を持つ社内CMSと、予約や会員機能とLINE連携を備えた店舗サイトの雛形を作り上げた。

制作の過程は約57,889字の記録としてまとめた。

ProプランでClaudeとClaude Codeを毎日使っていたが、5時間や1週間ごとの上限に当たって作業が止まる場面が増えていた。

1. CLAUDE.mdとrulesを必要最小限に削る
2. そのプロジェクトに要るskillsやmcpだけ読み込ませる
3. 対象ファイルのパスと参照元を先に渡し変更後の姿まで書く
4. 単純な調査はサブエージェントに任せ判断を本体に残さない
5. 話題が変わったら新セッションに移り区切りで/compactする

人が既に知っている情報を先に渡し、本当に探索が要る部分だけをClaudeに任せる形にしたことで、体感できるほどトークンの持ちが変わった。

context-modeはフックが有効な環境で最大約98%のトークン削減が見込めるとされる。

複数のAIが会話する様子を見せるだけのデモが多く、出来上がったファイルの作られ方や検証の通過状況をあとから追えなかった。

ログばかりが目立って成果物が脇役になっていた。

1. 一文の依頼からMasterが成果物と前提と依存関係を構造化出力で提案する
2. Runtimeが計画のスキーマや循環や担当や書込範囲や上限を先に検査する
3. 各Botに受信箱と作業領域を持たせ担当タスクと入力の参照だけを渡す
4. ReviewerがSHA-256のリビジョンに紐付けて検証し不合格ならBuilderが直す
5. 最終報告をモデルの要約ではなくイベントログから組み立てる

日本語の紹介LPとSNS投稿草案3案を頼んだ実行では、index.htmlやposts.mdなどが出てプログラム検証10件すべてがpassした。

Reviewer判定も6/6になった。

39ターンで$1.66、18分37秒で完了した。

77件のイベントログを無編集で公開している。

Claude Codeを本格的に使うと開発者1人あたり月200〜500ドル、時に2000ドルを超える費用がかかっていた。

質問に答えるため数千行のファイルを丸ごと読み込み、ほとんど使わない行まで課金される点が重かった。

1. 読み取りや定型生成を安いGemini 2.5 Flashに回す2つのモードを用意した
2. bulk-readerで大きなファイルを読ませ必要な情報だけ箇条書きで返させた
3. code-writerでテストや設定の雛形を作りファイルへ直接書き込んだ
4. プラグインshuntで350行超のReadを止めcatなど抜け道も塞いだ
5. 編集や深い推論や安全性が絡むコードはClaudeに任せた

Javaのモノレポで4つの場面を比べたところ、bulk-reader経由のときのClaude側のトークン消費は平均で約90%減った。

ただし委譲1回につき10〜30秒かかり、要約には正確な行番号が残らないため編集は任せられない。

電子請求書発行システム「楽楽明細」の新オプションを、実装に使える期間が1か月弱という条件で12機能ぶん作る必要があった。

要求仕様書は例外系や受け入れ条件が足りず、そのままAIに渡せる粒度ではなかった。

1. 決めた仕様をClaudeでプロトタイプ化し40社に見せて機能を約30%削った
2. 要件をEARS形式で1アクション単位に分け例外パスも書いた
3. kiro（cc-sdd）でspec化しエージェントに読ませた
4. Codexを主軸にgit worktreeで機能ごとに複数セッションを同時に走らせた
5. 一次レビューをGitHub CopilotとClaude Codeで出し人が二次で確認した

4月7日の開発決定から5月末リリースと実質2か月未満で出せた一方、12機能を1本のプルリクにまとめたため変更ファイルは700超、サーバーサイドのレビューは全量確認に5営業日かかった。

実装方針を決めきらなかったため同じ指摘を機能の数だけ受けた。

経営判断の前に財務やマーケの数字を手作業で集める必要があり、集計に時間を取られていた。

複数のAIを動かすと誤った数字が報告に混ざる心配もあった。

1. Claude Codeを核に9体の役をMarkdownのfrontmatterで定義した
2. CFOは会計API、CTOはリポジトリとCIと一次データの担当を分けた
3. CEOは各役の報告を統合するだけにして数字の創作を防いだ
4. 連携はinbox・today・archiveの3つのYAMLで秘書役が管理した
5. 月次決算の手順はSKILL.mdにまとめコマンドで呼び出せるようにした

CEO役が常にダッシュボードを更新するようになり、経営者の時間を集計から判断へ移せた。

ただし運用期間は短く、安定稼働と言えるかは今後の実績待ちだと本人は述べている。

営業に付随する細かい作業が積み重なり、毎週まとまった時間を取られていた。

1. 営業に関わる19の業務を洗い出す
2. 洗い出した業務に取り組む順番を決める
3. 各業務をClaude Codeに任せる形へ置き換える
4. 空いた時間の使い道を事前に決めておく

週14時間55分かかっていた作業が週54分になった。

一方で最初の2か月は商談数が1件も増えなかった。

社員がおらず、サイト制作や動画、経理の突き合わせといった作業を外に出すしかなかった。

中小企業のAI導入の話はうまくいった例ばかりで、実際にどこまで置き換わるのかが分からなかった。

1. コードを書かずに、やりたいことを言葉でClaude Codeに指示した
2. 作り直しの内容を伝えてホームページを自社で生成した
3. 机に並べた名刺をiPhoneで撮った写真12枚を渡してデータ化させた
4. 相手のサイトを読ませて法人向けメールを1社ずつ書かせた
5. 広告とLINEとサイトの数字をまとめた日報を毎朝8時30分に届かせた

外に出していた仕事をほぼやめ、少なく見積もって年300万円の外注費が消えた。

一方で無料で渡した業務用の道具8社分は誰にも使われ続けず、広告が6日間止まっていた期間は問い合わせが5件まで落ちた。

全社員にClaudeのTeamプランを配って個人の作業は速くなったが、各自が書いた手順書やスキルが個人の環境に閉じたままで会社の資産にならなかった。

さらに社員それぞれが業務アプリを動かすには保存や定期実行のできる本物のサーバが必要だった。

1. Claude Codeに切り替え1つのGitリポジトリへ文書とスキルを集約する
2. members/とteams/のディレクトリを作り個人の手順書を共有資産にする
3. アプリをCloudflareのWorkers for Platformsの上に置く
4. エージェントのコードは必ずPR経由で反映し履歴と巻き戻しを残す
5. 非エンジニアにはPRで確認用URLが出ることとマージで本番反映の2点だけ教える

非エンジニアが指示してClaudeが書いたアプリが、エンジニアの作るものと同じ厚みで本番を回すようになった。

エンジニア1人で作った基盤を5ヶ月運用し、社外APIの登録は40を超えた。

リサーチや資料作成、データ加工など小さな手作業が全社に散らばり、個別のシステム化がしにくかった。

AIを入れても使い方が個人任せだと、成果が人ごとの慣れに左右されてしまう。

1. 社員と業務委託の計59名に実行環境をそろえてClaude Codeを配る
2. 2026年7月から8月に全部門向け研修を行う
3. うまくいったやり方をスキルという手順書にして共有基盤へ登録する
4. 配色や書体やロゴの規定をAIが読める形に直す
5. 登録されたスキルをレビューして部門をまたいで共有する

2026年8月末までに45名の手で、手順書が743件、業務ごとのAIエージェントが127体たまった。

研修後の社内調査では、エンジニア以外の回答者のうち53％が毎日のように使っており、その中の69％が同じ成果物を作る時間は半分以下になったと答えた。

SEO記事はキーワード選びから競合調べや執筆をへて入稿まで工程が多い。

1本あたりの時間と費用がかさみ、外注すれば1記事数千円〜1万円かかっていた。

1. 人がキーワードを決め以降の工程をAIエージェントに渡す
2. 上位記事の見出し構成と文字数を調べH2/H3の構成案を作る
3. セクションごとに文字数を割り振り本文を書く
4. 11体のサブエージェントが観点別に並行で校閲する
5. 基準未達なら修正エージェントが直し再び校閲に回す

2025年から自社で回し続けた結果、月間3万PVを記録し複数のキーワードで検索上位を取った。

企業向け提供版のAPI利用料は100記事あたり約5万円前後が目安になっている。

請求サービスの開発で実装を自動化しようとしたが、速くなったのは個人の作業だけでチームに残る資産が積み上がらなかった。

暗黙知が多く、実装レビューの指摘も減らないままだった。

1. cc-sddを土台に設計書をDB・ドメイン・API・その他の4つに分ける
2. 工程ごとに命名規則やテスト実装ガイドなど社内ルールを読ませる
3. AI向けのdesign.mdとは別に人が読むHTML設計書を作る
4. 仕様の分割や事前調査など独自スキルを足して43スキルにした
5. PRコメントとIssueを集め繰り返す指摘をWikiにためる

設計書をレイヤーに分けたことで大きな影響が出るDB設計を早く見られるようになり、手戻りが減った。

一方でWikiには約700件たまったがスキルへの昇格は20件ほどで、週1のサイクルはまだ回しきれていない。

専任のエンジニアがいないまま各自がばらばらにClaude Codeを使い、仕様やコードが個人のチャット履歴やPCに埋もれていた。

確認不足のまま統合する危険や、不具合時に元へ戻す手順が無いことも不安だった。

1. 3日間の研修で開発の進め方を学んだ
2. 初日に画面とデータと処理のつながりを学んだ
3. AIの案をうのみにせず人が設計方針を決めた
4. 2日目にGitの変更履歴やブランチ運用を練習した
5. 3日目に現場の困りごとを要件にまとめアプリを作った

受講者の半数以上がプログラミング未経験だったが、最終日に8つの実務アプリをリリースした。

領収書PDFを一括で集める仕組みやAmazonのAPIと連携した在庫管理システムなどが生まれ、受講満足度は全日程・全項目で受講者全員が5点満点だった。

自動コードレビューをGitHub Actionsから従量課金のAPIで動かしていて、1回1ドル以上かかっていた。

費用をかけている割に安価なモデルでは指摘の質に満足できなかった。

1. Claude Codeのroutineにプルリク作成イベントをトリガー設定する
2. 変更内容を読ませてlow／medium／high／maxのレビュー深度を判定させる
3. その値を渡して組み込みの/code-reviewスキルを実行する
4. 指摘をインラインコメント、全体評価をまとめとして1レビューで投稿させる
5. 人はレポートを読んで取り込む指摘を選ぶ

GitHub Actionsのように自動で走る使い勝手を保ったまま、定額プランの範囲で上位モデルのレビューを回せるようになった。

同じ仕組みで日次E2Eテストの失敗調査や本番エラーの一次調査も任せ、開発中の割り込みがほぼなくなった。

社内ではClaude Code経由で業務を進めるほどAIを使うことは定着していた。

一方でRAGの中身やAIエージェントがツールを選ぶ仕組みは使うだけでは見えず、自社サービスに載せる方法も分からなかった。

1. 外部講師を招き2時間弱の講義で生成AIの全体像をつかむ
2. 手順資料に沿って各自が手を動かす形にした
3. S3に資料を置きBedrockのナレッジベースをコンソール操作だけで作る
4. Strands Agentsで3行のコードを書きAIエージェントを立ち上げた
5. ブラウザ操作のツールを持たせて調べものをさせた

S3への資料配置と数クリックで質問応答が動き、画像の中にしかいないマスコットもRAGが言い当てた。

研修を終えた新人の中には、覚えた進め方を実際の担当業務や開発に持ち込んだ人も出た。

広告配信基盤のDSPでは異常検知アラートが月に十数件〜数十件届き、その多くは自動で復旧するのに毎回10分〜1時間の調査が要った。

深夜や土日の対応が担当者の健康と日中の業務を圧迫していた。

1. GitHubのIssueにai-investigateラベルを付けAIが調査する流れを組む
2. 読み取り専用のサービスアカウントを切り書き込みを封じる
3. 過去につまずいた点をプロンプトに書き調査の取り違えを防ぐ
4. 特定できたときは管理画面のリンクも出させる
5. n8nでSlackのメンションからIssue起票とラベル付けを自動にする

アラートで起きたあとはSlackにメンションして10分タイマーで仮眠し、戻ってきた調査結果を読んで判断するだけになった。

過去事例を参照した対応方針も出るようになり、これまで調査に入りづらかった若手も仮説の検証から参加し始めた。

サブタスクを並行して走らせるとトークンを消費し気づくと5時間枠を使い切ってメインの作業が止まっていた。

Slackの依頼を仕分けるエージェントも裏で枠を食い続けていた。

1. Claude Codeのセッションに用途ごとのタグを付ける
2. タグ単位で5時間枠と7日枠の使用率の上限を決める
3. 公式の使用率の増分をトークン重みの比で各タグへ割り振る
4. UserPromptSubmitフックで送信前に上限を判定し止める
5. /tagスキルでタグの切り替えや上限の変更を行う

裏で動くタスクが決めた取り分に達した時点で自分から止まるようになり、メインの作業用のトークンを確保できるようになった。

実行環境を分けずに同じClaude Code上で運用できる。

AIエージェントに守らせたい決まりをCLAUDE.mdやAGENTS.mdに書き続けてきたが、それが本当に守られているのか分からなかった。

文書が古くなって参照先が壊れているのではという疑いもあった。

1. gitリポジトリ96本をスクリプトで走査し規約文書と総文字数を数えた
2. 規約文書から実行できる形のコマンドを正規表現で抜き出した
3. CI・pre-commit・huskyで同じコマンドが動くか突き合わせた
4. 先頭2語での照合をやめサブコマンドまで見る形に直した
5. .claude/のhooks有無と記載パスの実在も調べた

規約を持つのは96本中33本で総量は323,833字、実行できる形のコマンドは93個、そのうち違反を止められる場所で動いていたのは13個（14.0%）だった。

.claude/のhooksは33本中0本で、参照先が壊れている記述はほとんど無く、問題は鮮度ではなく実行されない書き方にあると分かった。

AIに作らせたスライドは見た目が自分のいつもの形と違い後から手直ししにくかった。

XML直編集や画像生成やHTML生成も試したが崩れたり自分の手で直せなかった。

1. python-pptxで表や見出しを作る関数群を用意する
2. 色と罫線とフォントと余白を関数の中に固定する
3. スキルに承認済みデザインと書き上書きを禁じる
4. スライド1枚をスクリプト1本にしgitで管理する
5. 値の範囲を外れたらエラーで止める形にする

ふだん手作業で作っていたものとよく似たスライドが自動で出てくるようになり、同僚が手作りと見分けられないほどになった。

出力はPowerPointの部品そのままなので文字の直しや表の組み替えも普段の操作で終わる。

入社1週間の技術研修はRailsとNuxtで小さなWebサービスをゼロから作る課題だが、AIに丸ごと任せれば1日で終わってしまう。

完成したアプリは残っても、自分には何も残らないという悩みがあった。

1. Claude Codeに教官役のルールを与えた
2. 方針と選択肢だけ説明させ答えは出させない
3. コードもコマンドも自分が書いて打つ
4. 勝手に実装したら訂正し教訓ファイルに保存させる
5. 詰まったらエラーの読み方を促してもらう

発展課題まで完走し、翌週から本体のコードに入った。

AIに任せれば1日で終わる分量に約7倍の時間をかけたが、自分で書いたコードの記憶があるぶん本体コードの吸収が速くなった。

紙の図面や検査記録が社内にあふれ、書類を探すだけで現場が1〜2時間動き回ることもあった。

創業50年でも手順書は50件ほどで、多くの作業のやり方はベテランの頭の中だけにあった。

1. AIとの対話を1500時間以上重ねコーディングを学んだ
2. タブレットとSlackで内線電話や紙探しをなくした
3. Claude Codeで社内アプリをフルスクラッチで内製した
4. 生産実績や設備稼働などを同じデータベースにひも付けた
5. 手順書アプリでAIが100点満点で採点し改善案を出す

月400〜500時間程度の作業時間を減らし、価格改定資料の作成時間は90％短縮した。

紙は月間約6000枚減り、手順書は1年足らずで290件集まった。

AIエージェントに頼むタスクは社内基盤で管理し人が担当するタスクは別のツールで管理していたため、両方を行き来する手間があった。

Slack経由でエージェントと会話する仕組みもAPIの制限でやりたいことが実現できなかった。

1. 社内AIエージェント基盤に全タスクの管理機能とグループチャット機能を自前で作る
2. 開発はClaude CodeやCodexに任せ3週間ほどで本番に出す
3. 表データやフォームの管理機能もAPIでエージェントが読み書きできるようにする
4. 権限の設計は社内で時間をかけて話し合って決める
5. 人はエージェントが作った内容を確認して直す

社員全員が自作のタスク管理とチャットに移り、AIエージェントと同じ場所で仕事をするようになった。

期間内に終わったタスクからリリースノートを書いたり、社内の回答集めのフォームを作って代行することもエージェントが自分でやるようになった。

認証認可APIを個人で作る際、生成AIに画面からDBまで一度に書かせたコードが自分の読める量を超え、レビューが追いつかなかった。

1. Java21とSpring Bootの認証認可APIを題材にする
2. 複数層をまとめて生成させた分はすべて元に戻す
3. DDDのレイヤード構成の層ごとに区切って生成させる
4. 自分が書ける粒度かを見て危ない箇所を手で直す

約7週間で73コミット、本体2,910行とテスト4,573行を作り、意図と違う実装で戻す事故は起きなかった。

ただし読む量が生成速度に追いつかず負荷は減らず、次はテストを手で書いてから実装を任せる形に変えることにした。

パーキンソン病と診断されたが公的支援制度は主体も窓口もばらばらで全体像がつかめず、治療の最新動向も主治医からの情報に偏っていた。

自分が欲しい情報をまとめた場所がどこにも見つからなかった。

1. 作りたいものの問いを自分で決める
2. 調査と要件のまとめをClaudeに任せる
3. 設計と実装と制度データの構造化をClaude Codeに書かせる
4. 治療情報の日次収集の仕組みもClaude Codeに作らせる
5. 出てきた成果を人がレビューし前提の誤りを直す

一人でParky Naviの初期版を公開するところまでこぎつけ、今は患者への聞き取りで内容を確かめている。

短期の目標として月間アクティブユーザー1万人を掲げている。

Claude Codeは調査や実装の結果に加えて背景や判断理由まで長く説明するため、要点を探すのに時間がかかっていた。

返答が長いぶんトークンの消費も積み上がっていた。

1. Claude Code内でコマンドを打ちgenshijinを入れる
2. 導入後は通常モードが常に効き設定も残る
3. 丁寧・通常・極限の3段階から通常モードを選ぶ
4. コードやファイルパスや数値は残したまま敬語を削る
5. 足りない部分は後から追加で質問して掘り下げる

返答が結論から始まるようになり、修正点を追いやすくなった。

社内のトークン利用状況でも導入した8月中旬以降は日別の推定コストが小さい日が増え、5時間枠を業務時間に合わせる運用と合わせてMax5xプランで作業が止まることはほぼなくなった。

長い設計書やソースコードをそのままAIに読ませると読み込む量が増え、場所を探すのにも時間がかかっていた。

人間向けの形式のままではエージェントの動きが遅くなる。

1. 設計知識をobjectiveやconceptなど8種類に分ける
2. 1ファイル2〜3ページの小さなYAML文書として貯める
3. ファイル間の行き来をjsonl形式のインデックスでたどる
4. 会話や要件のmarkdownを先に知識へ分解しコードを書かせる
5. リポジトリ間の変更は提案書を相手側の知識に評価させる

3つのリポジトリでコンセプト665・568・162件、相互リンク6,633・5,471・857件の知識を作り、Codex・Claude Code・GitHub Copilot・Grokのどれでも問題なく動いた。

エージェント同士を同じモデルで対立させたことで設計が洗練される場になった。

パッケージ時代から続く仕様書中心の開発の流れが残り、実装後に仕様書を書き直す手戻りも多かった。

AIを入れただけでは人の進め方が足かせになっていた。

1. 全社で使えるGeminiを土台に置く
2. 用途ごとにCursorやClaude Codeを使い分ける
3. 人が要求と制約を渡し設計から実装までAIに任せる
4. 仕様書をMarkdownに直しGitHubでまとめる
5. AIの実装を人が直しその成果物からAIに文書を作らせる

対象の開発案件で見積工数が約5分の1まで減った。

AIを使った開発手法のワークショップでは3日間でプロトタイプまで仕上がった。

月に3〜5本の取材記事を書いていたが、取材後の原稿づくりに1本あたり8時間かかっていた。

提出後に方向性の違いを指摘され、大幅に書き直すこともあった。

1. 取材をNottaで録音し固有名詞を単語登録で補う
2. 終了直後にインタビュー用テンプレートのAI要約で構造化する
3. 同席したクライアントとその場で内容をすり合わせる
4. 媒体条件のmdと要約をClaude Codeへ渡し構成案を複数出す
5. 執筆ルールのmdで初稿を書かせ1時間かけて表現を整える

記事1本にかかる時間が8時間から2時間になり、提出後に大幅な書き直しをすることがほぼなくなった。

受けられる案件が増え、単価も上げられた。