IT企業のAI活用事例

商談の内容で言った言わないの行き違いが起き、社内の引き継ぎでも聞いていないというもめ事があった。

議事録づくりの負担も重かった。

1. Web会議の商談をaileadで録画して文字起こしする
2. 担当が変わるときは前回までの録画を見て引き継ぐ
3. 話者分離で重要な人が話した部分だけを確認する
4. 月1回みんなで見て良い商談と悪い商談に分ける
5. コメント機能で気づいた点を書き込み進め方を直す

毎月130件ほどの録画がたまり、部署をまたいで商談のやり方を学べるようになった。

苦手なところだけを選んで見直せるので、メンバーが学ぶ機会が増えた。

個人開発のプロジェクトが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固定という制限はあるが、翻訳や要約なら実用になると分かった。

Databricks上でRAGチャットボットのPoCを進めていたが、回答の精度が悪いときに原因がチャンク分割か検索か質問か回答生成かを見分けられなかった。

全部に手を入れるしかないと感じ、着手点が決まらない状態が続いていた。

1. LLMOpsの勉強会と書籍で可観測性を知り既存コードに手を入れた
2. コード生成AIに相談し関数ごとにMLflowのトレース用デコレーターを付けた
3. アプリを動かしExperimentsで記録の抜けを見つけ順に見えるようにした
4. 自動トレーシングも戻す前提で試し重複する記録は後から外した
5. 検索で返った文書とチャンクの単位で中身を確かめた

約1ヶ月このやり方を続け、検索結果が同じ文書内のチャンクに偏る現象を見つけて検索ロジックの見直しにつなげた。

どの工程が悪いのかを部品ごとに見分けられるようになり、気持ちの負担も手間も大きく減った。

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

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

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

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

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

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

自作タスク管理ツールに繋いだAIエージェントをcronで定期実行していたが、進めるタスクが無い時間帯でも同じ間隔でLLMが起動していた。

空振りの実行でトークンを消費し、中身のない通知がSlackに流れ続けて重要な知らせが埋もれていた。

1. LLMを呼ぶ手前に起床判定の関数shouldWakeForTaskを置いた
2. 関数はタスク1件と利用者IDを受け取りbooleanだけ返す
3. 状態はタスクコメント1行目のマーカーに書き正規表現で読む
4. 最新マーカーはcreatedAtで選び再アサインなら再び起こす
5. 起こす条件と寝かせる条件をユニットテストで固定した

waitingやdoneのように待つべき状態では起動せず、再アサインや依存の解消、中断した作業の再開だけをエージェントに回せるようになった。

ただし定義外の状態名が入るとゲートが起床させない側に倒れる点は課題として残った。

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字の記録としてまとめた。

約30〜35のサービスを横断して月2万5,000〜3万件の問い合わせに応じており、オペレーターの負担が重かった。

wikiツールは検索が弱く、探すのが得意な人とそうでない人で処理速度に差が出ていた。

1. wikiにあった回答テンプレートをそのまま移した
2. 対応フローとテンプレートを一組にして登録した
3. アドオンでどの画面からでも呼び出せるようにした
4. 5〜10名でトライアルしてから正式に切り替えた
5. テンプレートを単独で更新できる形にした

一件あたりの対応時間が約30秒短くなった。

画面の行き来が減ってオペレーターのミスも減り、テンプレートの利用回数が見えるようになった。

ユーザーが疑問を持ったときはガイドを自分で探すか問い合わせフォームで連絡するしかなく、利用者が増えるほど解決までに時間がかかっていた。

有人対応では夜間に答えられない問題もあった。

1. Web版とスマホアプリ版にAIチャットボットを入れた
2. よくある疑問へ自動で答える形にした
3. 週一度の新機能公開に合わせQ&Aを足し直す運用を続けた
4. 出品に関する質問だけを取り出して調べ回答を厚くした
5. トレンドアラートで急増をつかみ同日に回答を作って共有した

導入から2年でチャットボットの利用者数が12倍になり、ほぼ二人に一人のユーザーの疑問を解決できるようになった。

人では難しい24時間の対応がかなった。

問い合わせ対応が担当者ごとに品質と速さがばらつき、新人が独り立ちするまで数ヶ月から半年かかっていた。

クラウドのWikiにナレッジを集めていたが日本語の検索が弱く、必要な情報にたどり着くのに時間がかかっていた。

1. ナレッジ管理やメール対応支援など複数ツールを比較する
2. 日本語に合う国産で画面が分かりやすいツールを選ぶ
3. 社内データベースの情報をすべて登録し約50名が実務で試す
4. メール作成画面からショートカットで呼び出し参照する
5. 導入の数ヶ月前から使い始める時期を社内に伝え続ける

カスタマーサービス部全体で月およそ450〜480時間の業務時間が減った。

後回しにしていた案件を自分から確認する人が増えるなど、時間への向き合い方も変わった。

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

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

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

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

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

AIエージェントへの指示が長い間ためこまれ、どれが今も効いているのか分からなくなっていた。

中身が古くなっても本人が気づけない状態だった。

1. 手元の指示ファイルとメモリを全部探し行数を数えた
2. 最大の392行ファイルを節ごとに分け行数順に並べた
3. 大きい節から直近1か月で使ったか自分に問うた
4. 消す・残す・別ファイルに逃がすの3つに仕分けた
5. 認証情報らしき文字列が混ざっていないか検索した

392行のうち大きい3節の合計181行が1か月間1度も使われておらず、1ファイルの46%が不要と分かった。

あわせて認証情報らしき2行も見つかった。

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

ツールを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%のトークン削減が見込めるとされる。

複数の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件のイベントログを無編集で公開している。

同じテンプレートからブラウザのプレビューとサーバのPDFが違う出力になり、24要素中18種が例外もログも出ないまま空で描画されていた。

既存テストはPDFが生成されたことしか見ておらず、ずれに気づく手段が目視比較しかなかった。

1. AIにコード全体をレビューさせEpicと子Issueを作らせた
2. 提示された12件から着手順を人が決めテスト基盤を最初に指定した
3. Issue番号と進める部分だけを10〜30分単位で指示した
4. 仕様が無い部分は実装前にAIへ仕様書を書かせた
5. Epicを閉じる条件に目視比較を加えて指示した

7月16日に立てた#52〜#64の13件はすべてその日のうちに閉じた。

ゴールデンPDFの回帰テストが安全網になり、フォントファイルの中身が違う問題や約1.4mmの縦ずれといった細かい差も特定できた。

CiscoやJuniperなどベンダーごとにコマンドの書き方が違い、手作業での置き換えに手間がかかっていた。

正規表現で作る変換スクリプトは複雑な設定や独自構文ですぐ壊れてしまう。

1. Bolt.newに2つの機器設定を左右で比べる画面を作らせた
2. 仮の変換処理をGemini APIの呼び出しに差し替えた
3. APIキーはブラウザのlocalStorageに置く作りを指示した
4. 変換の指示文に機器ごとの役割設定を組み込みJSONで注意書きを返させた
5. GitHubの非公開リポジトリ経由でVercelへ公開した

アイデアを出してから約2時間11分で、3カテゴリ・全16種のOSに対応した変換サイトを本番公開できた。

公開までの最初のデプロイは開始から約1時間20分で終わった。

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. UiPathと組み社内情報を探すAIアシスタントKAIを作った
2. 答えのもとになる資料を承認済みのものだけに絞る
3. 製品仕様や設備の空き状況や回線の性能まで返せるようにする
4. 安全面の制限を組み込み回答の正しさを何度も直していった
5. 社員はKAIの答えを顧客や社内への返答に使う

KAIは月11,300件の問い合わせのうち11,000件に答えており、回答までの時間は1〜5日から1〜3秒になった。

年間25,000〜30,000時間の手作業が減り、およそ12人分の余力が生まれた。

GitHubのコードをAIに触らせるならCodexを起動するしかないと思い込み、小さな修正でもエージェントの使用枠を減らしていた。

1. ChatGPTの通常チャットにGitHub連携をつなぎ対象リポジトリを読ませる
2. まず変更しないよう伝え影響範囲と依存関係を洗い出させる
3. 数ファイルならブランチ作成から修正とPull Request作成まで指示する
4. 過去記事を読ませて構成と文体をそろえMarkdownを直接追加させる
5. テストを何度も回す大規模な変更だけCodexへ渡す

通常チャットからブランチ作成やPull Request作成まで到達でき、この記事自体もCodexの作業環境を立ち上げずにリポジトリへ追加できた。

軽い変更を通常チャット側で処理する分、Codexなどが共有するエージェント枠を大きな開発に回せるようになった。

ChatGPTのチャットからnoteへ記事を投稿するMCPを作ったが、APIが通るだけでX投稿が普通のリンクカードになったり、画像を差し替えたつもりが公開ページに反映されないといった問題が続いた。

1. 利用者の目的から逆算し本文作成から公開反映までの完了条件を置いた
2. URLを判定する。X/Twitterのstatus URLは埋め込みで登録する
3. それ以外は外部記事カードとして登録し分けた
4. 生成画像は公式画像と見比べて人が監査しNGなら再生成する
5. 公開後はdetail APIで公開状態と画像の反映を検証した

HTTPの2xxではなく公開後の表示状態を成功条件にしたことで、表示が壊れたまま完了とみなす事態がなくなった。

再起動の判定も45秒のhealth監視だけで失敗と決めず、タスクの稼働とポートのListenと/healthの応答を分けて見るようにした。

電子請求書発行システム「楽楽明細」の新オプションを、実装に使える期間が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分かかるが、打ち切りを入れて実用の範囲に収めた。

一人ひとりが持つ仕事のコツややり方が個人に閉じたままで、社内で共有されにくかった。

AIを配っただけでは現場の仕事に合った使い方が広がらないという壁もあった。

1. 社内の推進組織が中心となりGemini Enterpriseを全社に導入した
2. 社員が自分の担当業務に合わせた小さなAIエージェントを自作できるようにした
3. エージェントに各自の手順や判断の勘所を書き込ませた
4. 使うだけの段階から社員が自分で作る段階へ広げた

導入から5か月で、社員が自発的に作った業務特化エージェントは約2万個になった。

社内に埋もれていた暗黙知が目に見える形になり、この取り組みはGoogleのクラウド関連の大規模イベントの基調講演でも先行例として語られた。

Codexの5時間ごとの利用枠は最初のメッセージを送った時点から始まるため、開始時刻が日によってずれて作業時間と噛み合わなかった。

1. ChatGPTのMacアプリのWorkからScheduled Taskを作る
2. 毎日午前4時にPINGだけ返す軽い指示を登録した
3. 実行はNew chat each runにして会話を引き継がない形にする
4. モデルはGPT 5.6 Luna、ReasoningはLightを選ぶ
5. 翌朝SettingsのUsageでリセット時刻を確かめる

翌朝のUsage表示では5時間枠のリセットが9:14 AMとなり、4時14分ごろに枠が始まったと推定できた。

PINGだけの実行だったため残量は100% leftのままで、目立った消費は見られなかった。

アプリを作るには開発環境の用意やサンプルデータの準備が必要で、興味はあっても試すところまで進みにくかった。

1. 業務で使うSharePointリストのサイトを開く
2. 列構成とデータを分析しダッシュボードを作るよう文章で指示した
3. HTMLファイルをSharePointに保存しリンクを返すまで指示に含めた
4. 出来上がった画面をプレビューで開き動作を確かめた
5. チャットで追加のグラフや配置の修正を頼んだ

指示から1分ほどでHTMLのダッシュボードが出来上がり、件数や対応状況のカードと一覧表、絞り込みが使える形になった。

キーワード検索はファイルビューアー上で文字入力がうまくいかず、動作の確認は人がやる必要があった。

AI検索で自社サービスが紹介されているかを調べるため、複数の生成AIに担当者が手でプロンプトを打ち込み、回答をスプレッドシートにまとめていた。

工数が重いうえ、担当者ごとに回答が寄ってしまい客観的な数字が取りにくかった。

1. フロント向け2サービスの商材カテゴリーを軸にプロンプトを20個用意する
2. LLMリサーチでサービス名の出現割合とURL引用割合の2指標を測る
3. API経由で定期的に計測しレポートをワンクリックで出す
4. リスティング広告のデータを見て検索意図に近い言い回しへ直す
5. 人は数字を読んで次の打ち手を決める部分に回る

特定のプロンプトでのブランド露出率が導入前の水準と比べて130％になり、全リードに占めるAI起点リードの含有率は半年間で30％増えた。

集計の手間が減り、分析や打ち手を考える時間を増やせた。

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

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

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

営業の残業はほぼなくなり、システム開発の生産性は半年で約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役が常にダッシュボードを更新するようになり、経営者の時間を集計から判断へ移せた。

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

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

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

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

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

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

GA4や定型レポートでページビューなどの個別の数値は見えても、訪問者がどこから来てどのページを通り次に何をしたかという流れがつかめなかった。

そのためサイトの直し方が感覚頼りになっていた。

1. サイト分析にデタクルを導入する
2. GA4からBigQueryへ出したデータを期間やページで絞って取り出す
3. 取り出したデータを生成AIが読める形に整えて渡す
4. 流入元や経由ページ、端末別の行動差の切り口で結果を出す
5. 結果を対話で掘り下げて改善案にまとめる

集計値だけでは気づけなかった行動が見えるようになり、サイト改善の新しい仮説が出せるようになった。

レポートを報告して終わりでなく、データを根拠にボタンの大きさなど具体的な直し方をその場で話し合えるようになった。

高齢の親や愛犬と出かけるため、ペット可の宿だけでなく犬と入れる観光施設や飲食店まで一つずつ調べる必要があった。

候補探しに手間がかかり、計画づくりに数日を要していた。

1. 行き先と目的を書いてGeminiに渡す
2. 同行者の人数と年齢を添える
3. 予算や日数や行きたい場所を条件に書く
4. 定休日や天気予報をもとに日程を直す
5. 宿や航空券の予約まで進める

国内でも海外でも、以前は数日がかりだった旅行の計画と手配が2時間ほどで終わるようになった。

同行者に合わせた提案が返るため、条件探しの負担が大きく減った。