Claudeの活用事例

3年以上続けた音声配信が本当に誰かの役に立っているのか確信が持てなかった。

案件や広告を受けない方針のまま収益が伸びるのかも分からなかった。

1. Claudeに専用プロジェクトを1つ用意する
2. 配信の文字起こしとブログ記事を入れる
3. 参考資料と自分の考え方もまとめて置く
4. 過去のやり取りを全部読んだうえで検証を頼む
5. 問いは役立つかと収益になるかの2つに絞る

役に立っている相手と収益になる相手がズレているという答えが返ってきた。

伸びない原因は方針ではなく、検索される題材でないことと支払い先への導線が弱いことだと示され、条件のままの天井として年間10〜30万円という試算も出た。

4年前に自分で作った日報の仕組みは数量や時間の欄は問題なかったが、自由記述の表記ゆれや誤字で過去の記録が検索に引っかからなかった。

トラブルの処置や次の直への申し送りといった大事な情報が、残っているのに使えない状態になっていた。

1. 日報のテキストをClaudeのAPIに渡し決めた形に構造化させる
2. 表記ゆれの名寄せと日付や単位の統一をさせる
3. 記入漏れや矛盾は品質の指摘として出させる
4. 未記入は計算で埋めずnullにするよう指示文で禁じる
5. 整えたデータを複数日まとめて渡し繰り返しやずれを探させる

OCRの崩れや全角半角の混在を含む架空の日報14枚で試したところ、外径が一方向に増えているのに公差の記載がない点や、トラブル欄に記載があるのに時間が0.0hになっている矛盾を出せた。

申し送りの懸念が扱われず同じ損失が再び起きていることも見つかり、費用は1枚の正規化が約10円、14枚の横断分析が約30円だった。

バッチ処理の途中でレート制限のエラーが続き、とりあえず待って再実行するという場当たりの対処をしていた。

その結果リトライが重なって制限をさらに食いつぶす悪循環になっていた。

1. 例外を文字列でなくクラスで捕まえ、429と529を分岐させた
2. 生のレスポンスから制限種別と待ち時間のヘッダーを常時確認した
3. リトライはPython SDKの自動リトライ回数に任せ外側では書かない
4. 自前で組む場合はSDK側の回数を0にして役割を一つにまとめる
5. 残トークン数のヘッダーで同時実行数を絞り入力トークンを事前に数える

外側のリトライを重ねた状態では1回の処理が最大9回のリクエストに膨らんでいたが、役割を分けて解消した。

エラーをただ待って潰すのをやめてヘッダーを読むようにしたことで、バッチの安定性が目に見えて変わった。

副業で受けた開発案件に時間がかかりすぎ、報酬に対して実質の時給が下がっていた。

ツールを1つに絞ると得意でない工程で手が止まる。

1. 案件を4タイプに分けて使うツールを先に決める
2. 既存コードの修正はGitHub Copilotの補完提案をそのまま試す
3. 小規模サイトはCursorで骨組みだけ手書きし残りを生成させる
4. 中規模アプリはClaudeに画面構成とAPI設計とDB設計を出させる
5. 要望があいまいな案件はClaudeで機能候補と優先順位を整理する

ポートフォリオサイト制作は8時間で終わり、所要時間が60%削減された。

中規模アプリ開発は約120時間で、所要時間が40%削減された。

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

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

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

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

電子請求書発行システム「楽楽明細」の新オプションを、実装に使える期間が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営業日かかった。

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

既製の基板4枚をつないだ6キーのマクロパッドは動いたが、もっと薄く小さくするには専用基板が要った。

自分は基板設計の専門ではなく、手作業でゼロから起こすのが難しかった。

1. EasyEDA ProのAPIにJavaScriptを投げAIから基板を操作する
2. 回路図と配置を作らせトークン切れでClaudeからGrokへ交代する
3. 部品41個・パッド214個・配線120本を突き合わせる監査を書かせる
4. オートルータが動かないため自前のグリッド探索ルータを書かせる
5. Codexに引き継ぎコストに曲がり回数とビアを入れる修正をさせる

Claudeのグリッドルータが引いた722本・105ビアの基板は、Codexの書き直しで151本・33ビアになった。

探索時間はCPUで6分半・実時間10分かかるが、打ち切りを入れて実用の範囲に収めた。

大手企業が中心のフィールドセールスから、より広い市場へ営業を広げる必要があった。

提案書づくりやデータ集計といった決まった作業に時間を取られていた。

1. 月1日はAIだけで仕事をする「AIデー」を設けた
2. 社内のAI資格と支援金を用意し営業部門の全員がAIを使う状態をつくった
3. 提案書の作成やデータ集計と議事録づくりをAIに任せた
4. 約1,400万件の企業データベースSalesNowをMCPでClaudeとつないだ
5. Salesforceのデータも重ね部署や役職まで絞ってアプローチした

営業の残業はほぼなくなり、システム開発の生産性は半年で約5倍になった。

翌年にはアプローチから返信対応までの自動化も進める。

MCPサーバーを増やした結果、認証トークンやCookieの期限切れ、ローカルサーバーの停止に気づけなくなった。

タスクを頼んだ途中で止まり、原因の切り分けに手間がかかっていた。

1. GA4など8種類以上のMCPサーバーを1つの設定ファイルにまとめる
2. 認証方式を4つに分け鍵の置き場所とログイン手順を決める
3. 作業開始時に各MCPの状態確認を1行のプロンプトで頼む
4. 副作用のない確認用ツールを順に呼び生死を一覧で返させる
5. 落ちていたものだけ人が再ログインやOAuthを取り直す

作業の途中でトークン切れによって止まる失敗がなくなった。

どのMCPが落ちたかがすぐ分かるため、再認証は1分以内で終わるようになった。

スキルシートを一度書くと見直さないまま面談を迎えていた。

自分では当たり前と感じている経験が書く価値のある強みかどうか判断しづらかった。

1. 採用担当者の立場で深掘り質問をさせる指示書を作る
2. スキルシートと自分の技術記事を渡して一問一答で掘り下げる
3. 聞き出した内容を書く価値があるかAIに判定させる
4. 数字や固有名詞を残して短くまとめさせる
5. AIが理解した内容を毎回確認してから次へ進む

定量的な成果の記載が1件、属人化を解消したエピソードが1件加わり、曖昧だった表現が実態に合う形に直った。

書面上は運用保守中心の印象に見えていることも分かった。

上位プランや無制限課金を並行して契約すると月3万〜5万円まで膨らみ、かといって無料枠だけでは上限にすぐ当たって手が止まっていた。

1. ChatGPTに雑なアイデアを渡し要件定義とタスク分解をさせる
2. 結果をspecs配下のMarkdownとしてローカルに置く
3. そのファイルをAntigravity無料枠に読ませ生成やGit操作を自律実行させる
4. Cursorのインライン補完でコードを仕上げGitHubへ送る
5. PR差分とテストログをClaudeに投げ分析とリリースノートを任せる

月額は合計で約9,000円〜10,000円に収まり、上位プランをまとめて契約した場合の約30,000円〜50,000円と比べて安く済んだ。

役割を4つに分けたことで一つのツールが制限に達しても作業が止まらなくなった。

医療保健や健診、妊婦の手続きなどの窓口に同じ内容の問い合わせが電話や来庁で何度も寄せられ、職員が1件ごとに数分から20分ほどかけて答えていた。

人口減少で職員が減る中、行政サービスを保てるかが不安だった。

1. 職員に負担を感じる業務を聞き取り対象を決めた
2. 公式サイトを週1回巡回し文章を分けてRAG化した
3. 質問に関連する部分を探しClaude Sonnetが回答を作る
4. チャットボット画面をVoiceflowで組みAPIで接続した
5. 73日間の実証で精度と反応を確かめ本番運用に移した

実証時の利用が1年続いた場合、年間で約590時間の業務削減になると見込んだ。

利用者アンケート118件のうち83％が役に立ったと答えた。

全社員に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. 全社員にClaude Enterpriseの利用環境を用意した
2. 管理部門が資料作成と数値集計を任せた
3. 規程と書類のつき合わせをAIに任せた
4. 営業部門が提案資料の書式そろえと文章の練り直しに使った
5. 出力は人が中身を確かめる運用をルールにした

回答者の7割がほぼ毎日使い、管理部門では一人あたり1日約1.5時間、月約30時間を減らした。

書類を横断して確かめる作業では90%を超える削減率の例も出て、2026年7月時点で単月18%の作業時間削減を確かめた。

全社員が使う生成AIアシスタントでは、推論とデータを国内に閉じることや監査ログ・コスト管理といった条件を後から足せない。

会話履歴やプロジェクト設定は方式をまたいで引き継げないため、数万人が使い始めてから基盤を移すと人手での再構築が必要になる。

1. Claude Desktopの推論先をAmazon Bedrockに向ける構成を選んだ
2. 国内リージョン間で推論を完結させ性能設計と負荷テストを2週間の工程に組み込んだ
3. 接続先ごとに異なるMCPやOAuthの差を吸収する認可中継サーバーを自前で設計した
4. リリース1週間前の認可の不具合をAWSのエンジニアと実機で切り分けた
5. 統括チームと社内SEチームとAWS側専門チームの3者体制で進めた

2026年6月1日に最大12万人が使える本番環境が立ち上がり、7月時点まで約2か月間を大きなトラブルなく動かしている。

利用者は8月18日時点で11,000名まで広がり、認可中継サーバーは7月18日に社内公開して接続先を順次増やしている。

業務効果の数値での測定は今後の課題としている。

調査や設計や実装をAIに任せると、記憶だけで確認を済ませたり終わりを決めずに過去まで遡り続けたりして、作業が空回りしていた。

まだ作らない機能まで設計書に書き足され、今作るものが見えなくなることもあった。

1. 調査や整理や設計や実装をClaudeに任せる
2. どこまで調べるかと何を今作るかは自分で決める
3. 確認は記憶に頼らせず実際の検索結果で照合させる
4. 調査依頼は対象と範囲と終了条件を先に渡す
5. 指示書を今の実装と突き合わせ済み項目を外す

直っている箇所を作り直す無駄が消え、daily-stackの改修はその日のうちに仕上がった。

調査が過去まで際限なく潜る事故も、範囲と終了条件を先に渡すことで止まるようになった。

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

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

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

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

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

バナー広告は多くのパターンを試す必要があるが、Codexだけで画像生成から入稿までをまとめようとすると1枚で残り使用量の10%ほどを消費してしまい枚数を増やせなかった。

ChatGPTとCodexを分ける運用にしても、毎回プロンプトと参照画像を渡し直す手間が残った。

1. Codexに生成から登録まで任せたが重く断念した
2. 画像生成はChatGPT、登録と分析はCodexに分担した
3. CodexからComputer UseでChatGPTを操作する方法も試した
4. OpenAIのAPIから直接画像を生成する形に変えた
5. 生成用スキルに品質や判断の基準を細かく書き込んだ

ChatGPTのライセンスが不要になり、もとから使っていたClaudeだけを入口にして生成から登録までの流れを回せるようになった。

Deep Researchは調べ物を数十分で終わらせてくれるが、出てくるレポートが何万字もあり読み通すのが重い。

中身は良くても全体をつかむまでに時間がかかっていた。

1. ChatGPTにリサーチ用の指示文を書かせる
2. その指示文でDeep Researchを走らせる
3. 出たレポートをMarkdownで保存しChatGPTに読ませる
4. HTML化の指示文を作らせそのままHTML出力させる
5. グラフのラベル重なりなど見た目の粗を直す

文字がびっしり並んだレポートが、グラフや表や折りたためる見出しの付いた資料に変わり全体をつかみやすくなった。

無料アカウントでも実用に足る出来で、有料との差は主に見た目だった。

年間30件以上のゲームタイトルのソースコードレビューを2〜3名のエンジニアが目で確かめており、1回に2〜3日かかっていた。

開発パートナーごとに作りや使う技術が違い外国語のコメントも混ざるため、確認する範囲が広がっていた。

1. 差分ではなくソースコードを丸ごとAIに渡す
2. 20万トークン対応と非学習規約でClaude 3.5 Sonnetを選ぶ
3. ZIPを上げると対象ファイルとレビューデータを作る
4. 出た提案をもう一度Claudeに評価させ優先度順に並べる
5. エンジニアは結果をもとに2次レビューで深く確かめる

ファイルサイズ6.5MBのサーバーサイドのコードで約45分で1次レビューが終わり、2〜3日かかっていた作業が1時間から半日程度になった。

レビュー全体の期間は5営業日のままとし、2次レビューで幅広い観点から深く指摘できるようになった。

コロナ禍で出社できる人だけで仕事を回す必要が生じ、ベテランの経験に頼った進め方が続かなくなった。

個人への依存を減らし、誰がやっても同じ結果を出せる仕組みが求められていた。

1. AWS上でAmazon Bedrockを選び生成AI基盤を決めた
2. 公開のGenUを土台に自社向けAI画面を作った
3. 営業サポートは専門用語をClaudeに聞き表で資料化した
4. デザイン部門はTシャツ図案を画像生成し添削にも使った
5. EC担当はSQLエラーをAIに相談し社内エンジニアが指導した

デザイン部門を除く4部門で月あたり合計450時間の工数を減らした。

デザイナーは1案件あたり2時間短くなり、外注で1週間かかっていた図案も画像だけなら10秒で出せるようになった。

ニュースのネット配信を増やしたくても、人を割いて制作するとコストがかかりすぎた。

記者の数が限られ、書き手によって原稿の質や作業時間にばらつきもあった。

1. FAXのリリースを複合機でPDF化し文字認識をかける
2. 読み取った内容をDynamoDBにため管理画面で見られるようにする
3. 取材メモを足しClaudeで原稿を3パターン出す
4. スタッフが1案を選び手を入れて記事に仕上げる
5. ナレーションはAmazon Pollyで読み上げ縦型動画にする

原稿は1回2分ほどで生成でき、追加コストは1記事あたり数円程度。

ショート動画の制作時間は30分〜1時間から5〜10分に縮まり、毎月100〜120本のコンテンツを増やせるようになった。

プルリクエストのレビューに開発者の時間が取られていた。

小規模なデータ分析に合うサービスも無く、汎用のAIアプリでは機能が足りず特化型は高価だった。

1. OSSのPR-AgentにBedrock経由のClaudeをつなぐ
2. プルリクエストの一次レビューをAIに任せる
3. 狙った出力が出るまでプロンプトを調整しGitHub Wikiで管理する
4. Amazon BedrockとAWS Lambdaでサーバーレスの簡易基盤を組む
5. 参照データとシステムプロンプトを先に渡し要約や検索に使う

Xのフォロワー分析の案件で工数を50％程度削減した。

10分ほどかかっていたプルリクエストのタイトルと説明文の作成が瞬時に終わるようになり、レビューの精度も上がった。

RAGを入れた顧客から、試作では精度が出たのに実務で使うと回答の質が落ちるという声が多く寄せられていた。

誤った回答が社内に広まる不安もあった。

1. 自社開発基盤からAmazon Bedrockを直接呼び出す
2. 複数のLLMをAPIで選べるようにする
3. ユーザーが回答を評価し高評価の回答をキャッシュDBにためる
4. 似た質問はRAGを通さず即座に返す
5. オペレーターが手で登録するアンサーDBを用意する

2024年4月から5月の1か月で開発し、テンプレートとしてリリースした。

大手金融機関や交通インフラ系の企業がPoCを進めており、最短2か月ほどで導入できるようになった。

ESG評価に必要な非財務情報は企業ごとに様式の違うPDFに散らばっており、抽出作業に時間と手間がかかっていた。

社内チャットだけでは検索の質と効率に限界が残った。

1. 環境分野で対話する約70社の統合報告書3年分を対象に決める
2. 独自の評価観点から検索キーワードを決めてベクトル検索をかける
3. Claude 3 Opusが検索結果から関係する記述を選び要約を作る
4. 要約をファイルに出し社内チャットのカスタム機能から呼び出せるようにする
5. 要約にPDFの該当箇所へのリンクを付け元文書で確かめられるようにする

統合報告書の分析業務は3〜5倍に効率化され、現場の作業時間は従来の3分の1程度に短縮された。

キーワード検索では見落としがちな記述も意味で拾えるようになった。

人手が足りない自治体では業務が多様になり複雑になっていた。

行政専用ネットワークのLGWANでは国内にデータを置く必要があり、そのままでは生成AIを使えなかった。

1. 国内にデータセンターがあるAWS上に生成AIチャットを作った
2. モデルを切り替えられるAmazon Bedrockを土台にした
3. 2024年3月にClaude 2.1を本番へ入れた
4. 個人情報の入力時に警告を出すマスキング機能を付けた
5. Amazon KendraのRAGで市のマニュアルを読ませ回答させた

広域自治体を含む約60自治体で使われるようになった。

市のマニュアルに沿った回答が返るようになり間違いが減り、挨拶文なども手直しの手間が減った。

商談解析サービスJamRollの自動要約に使っていた他社のLLMでは1時間を超える会議を一度に要約できなかった。

テキストを分けて中間要約をつなぐ方式のため品質が安定しなかった。

1. 複数のLLMを日本語性能と単価と相性で比べて選ぶ
2. 音声認識した商談の全文を分割せず一度に要約させる
3. 出力を決まった形に構造化させプロンプトを整える
4. XMLタグでタイムスタンプを指定し本文と要約を並べる
5. クォータ超過を避け複数アカウントに分散する

導入は1か月ほどで終わり、2024年4月に切り替えた。

要約の精度が上がってJamRollの成約率は従来のLLM比で1.5倍になり、初回商談から受注までの期間も短くなった。

新しいプロジェクトの担当者を選ぶとき異動履歴やスキル資格評価キャリアプランなど複数の人事データを見比べる必要があり、候補者探しに手間がかかっていた。

1. 自然文の人材イメージから候補者を探す機能を人事システムに作った
2. 土台にAmazon BedrockとClaude 3.5 Sonnetを使った
3. AWSの支援で技術者が基本構成を設計しプロトタイプを作った
4. サンプルコードをもとに自社の開発チームが製品にした
5. ベクトル検索の候補をLLMで適合度判定し権限を4段階に分けた

着手から5か月で新機能をリリースし、プロトタイプは2か月で作った。

SaaSの基盤と生成AIをAWSにそろえたことで個人情報を扱う機能を安全に作れた。

人手が足りず配送担当者向けのリーフレットや広報紙の制作、会議の議題準備と議事録づくりに時間がかかっていた。

外部のAIに機密情報を入れると学習される心配もあった。

1. 2024年4月にAmazon Bedrockを土台にした社内向けアプリを作った
2. 長文応答はClaude、要約や分類はAmazon Titanを使った
3. 画像づくりにはStable Diffusionを使い分けた
4. 会議録画から文字起こしと要約を自動生成し、確認は人が行う
5. まず約100名で始め、約4,000人への展開を進めた

会議資料は最初から3割ほどできた状態で始められるようになり、広報物の写真撮影や業者とのやりとりの時間は70%程度減る見込みになった。

社内マニュアルを検索先に入れたことでヘルプデスクへの問い合わせも減った。

移住相談用のLINEチャットボットは辞書に登録した質問にしか答えられず会話が続かなかった。

答えられない質問は職員が手作業で返していて早朝や休日の対応が難しく負担も重かった。

1. 外部サービスの提供終了を機にAmazon Bedrockへ移行した
2. 特定の語を含む質問は検証済みの辞書から返す
3. 該当が無ければRetrieve APIで回答データを探す
4. 信頼度が足りない時はClaudeに文案を作らせ職員が直す
5. マスコットの親しみやすい口調を保った

文脈をふまえた自然なやり取りができるようになり、ほとんどの質問にその場で答えられるようになった。

サーバーレス構成をそのまま使い、従来の予算内で運用できている。

庭やアプローチの植栽は施工業者と発注者で完成像をそろえるのが難しく、引き渡し時のずれが満足度を下げていた。

CADで図面を起こす方法はお金も時間もかかり気軽に使えなかった。

1. 植栽を入れたい場所の写真を受け取る形にした。
2. 庭の雰囲気をメニューから選ばせる仕組みにした。
3. Amazon Bedrock経由のInpaintingで一部だけ描き替えた。
4. 理想に近い庭の写真をClaude 3 Haikuに渡し指示文を書かせた。
5. 生成された指示文を画像生成側に入れ絵を見ながら調整した。

開発期間2か月でgardenAIを公開し、外構・エクステリアや建築・建設まで届く範囲が広がってビジネス機会が増えた。

ハンワホームズが本エンジンを組み込んだ外構提案システムniwa U-Mを出すなど、使われ方も出てきた。

動画配信や電子書籍に毎日1,000件以上のレビューが届き、その1割以上が規約違反だった。

熟練の担当者が月に約200時間をかけて目視で確かめており、精神的な重さと費用がかさんでいた。

1. 既存のAWS基盤上にAmazon Bedrockで承認の仕組みを作った
2. サンプル50件で各社のAIを比べClaude 3 Haikuを土台にした
3. ルールで明らかな違反を拾い次に粗く選り分ける
4. 誹謗中傷など10種類以上の区分で細かく見て再判定する
5. 理由つきで管理画面に出しモデレーターが最終判断する

2024年10月時点でAIの判定精度は98％以上になり、レビュー投稿から判定まで30〜60秒で済むようになった。

1日あたり約30ドルの費用で回り、担当者はAIの判断を確かめて決める役割へ変わった。

HULFT製品のサポートでは数万ページに及ぶマニュアルやFAQ、過去の問い合わせ履歴から答えを探す必要があり、経験の浅いエンジニアほど回答づくりの負担が大きかった。

1. 社内のサポート担当向けにRAGの仕組みを作った。
2. 3案を製品の認定試験の数100問で比べ正答率が高いAdvanced RAGを選んだ。
3. 公開のGenerative AI Use Cases JPを作り変えて仕組みとつないだ。
4. 3つのモデルの答えを並べて比べClaude 3.5 Sonnetを採った。
5. 法務部門の助言をもとに入出力をチェックする制御を入れた。

社内のサポートでは回答作成の時間を最大30％短縮した。

AIアシスタントは約2か月で開発を終え、社内約300名への調査では80％が役立つと答え業務効率は平均24％上がった。

開発そのもののAI化が進む一方で、開発以外の雑務に時間を取られていた。

なかでも社内から届く問い合わせの調査が負担になっていた。

1. Slackワークフローから問い合わせのIssueを1件立てる
2. 決められたラベルが付いた時だけGitHub Actionsを動かす
3. Sessions APIでセッションを作りリポジトリ名とIssue番号だけを渡す
4. GitHubとSlackのMCPツールだけを有効にし探す先を限定する
5. 範囲外の質問には推測せず担当外と返す形にする

利用者はSlackで問い合わせを送るだけで、Issueに出典付きの回答が付き、スレッドにも結論の要約が届くようになった。

エージェントのループと実行環境はAnthropic側にあるため、常時動かすコンテナや実行基盤を持たずに済み、待機時間の費用も不要になった。

治験計画の届出後に来る照会への回答づくりでは、似た質問や事例を人手で探して文章を組み立てるため時間がかかっていた。

全社で生成AIを使う土台も整っていなかった。

1. AWSの全社クラウド基盤にAmazon Bedrockを組み込む
2. 社員とAWS担当でスクラムチームを作り1週間ごとに計画とレビューを回す
3. 1画面で複数LLMを選べる形にし入力を再学習に使わない設定にする
4. 社内データをRAGでつなぎ照会回答の下書きをAIに作らせる
5. 担当者が中身を確かめて仕上げ週次リリースでひな形を増やす

2024年10月時点で全社員の約80%にあたる約6,000人が使うようになった。

照会対応の一例では約57%の業務削減につながった。

IoTのデータを複数組み合わせてAIで判断し機器の制御へ返す仕組みの求めが増えていた。

ただしAIのAPIを呼ぶには開発の手間がかかり、着手までの壁が高かった。

1. 社内のアイデア出しの案をAWSサーバーレス構成で組み立てた
2. Lambdaなどを軸に処理を小さく分け非同期でつないだ
3. 生成AIの呼び出しはAmazon Bedrock経由にした
4. Claude 3など複数モデルから選べる形にした
5. 最小限動くものを作り機器や外部システムへ広げた

実際の開発期間は5か月で、2024年7月に公開した。

従来は数か月かかったIoTアプリの開発が、初めてでも数日から数週間でできるようになった。

あったらいいと思うアプリを自分で形にしたかったが、プログラミングの経験がまったく無かった。

生配信の視聴者参加企画を回す仕組みも、既製のサービスでは用意できなかった。

1. ChatGPTにコードを書かせNode.jsのプログラムを作った
2. 直しは部分修正でなく全文を書き直させて進めた
3. CursorとGitHubとVercelの開発手順を教わった
4. 移動中にスマホで仕様をMarkdownにまとめた
5. 帰宅後に仕様書をAIへ読ませClaude Codeで開発した

Xへの購入報告や応援ポストの数に応じて衣装や映像素材が使えるようになる仕組みと、元のMVとの再現度をAIが採点する機能を組み込み、2026年7月31日の約10時間の生配信で動かした。

Claude Codeを使い始めてから開発の速さが大きく上がった。

ローカルのファイル操作やOSコマンド実行までできるAIエージェントを全従業員に配ると、情報漏えいや誤操作の危険が大きい。

かといって一律に禁止すると、現場のスピードが落ちる。

1. 2026年5月からClaude CodeとClaude Coworkを全社に配った
2. 非エンジニアにはNotion AIと仮想環境のClaude Coworkだけを渡した
3. JamfとOktaをつなぎ開発者か非開発者かで設定を自動配布した
4. 非エンジニア端末の管理者権限を外しSlackコマンドで一定時間だけ付与した
5. API利用はLiteLLMを通しGKE上で短い有効期限のキーを自動発行した

1000人以上の非エンジニアにもエージェントを前提とした働き方が広がり、これまでエンジニアに頼むしかなかったプロダクトマネジャーが自分で新機能を実装してリリースする例が出てきた。

共通基盤でAIの費用をまとめて見られるようになり、チームごとのコスト調整も提案しやすくなった。

PowerPointのCopilotに資料作りを任せたいが、いつも使っているデザインとは違う見た目のスライドしか出てこなかった。

1. Copilotが読み込むサンプル用テンプレートファイルを用意した
2. 手持ち資料が無いためCopilotに資料を作らせレイアウトを足した
3. ClaudeのOpus5に既存スライドの配色やフォントや余白を分析させた
4. 分析を共通ルールと例外と要確認の3つに分けさせた
5. 23種類のレイアウトを必須とし空欄はダミーで埋めさせた

Copilotがデザインの特徴を読み取れるテンプレートの形が見えてきて、テーマ定義とスライドマスターとレイアウトの整備を段階的に進められるようになった。

参考にする広告やLPを探すたびに分析ツールを開いて条件を設定し、ランキングを上から一件ずつ見比べる必要があった。

まとめ直してチームへ共有する手間もかかっていた。

1. MCPで主要15媒体の広告データベースをClaudeやChatGPTにつなぐ
2. 同じジャンルのスワイプ型LPを10件のように条件を言葉で伝える
3. 抽出結果を見出しや構成などの構造化データで受け取る
4. 競合上位10社の広告と分析を週1回チームチャットへ自動配信する
5. 出てきた材料を見て人が構成や制作の方針を決める

LPの参考リサーチが約1時間から約15分になり、競合調査の手間は体感で約1/20に減った。

市場データと自社データをAIでまとめて制作の自動化までつないだ会社では、広告関連の業務が月50〜100時間減った。