AI活用事例ナビ

シャドーイング添削サービスで、アプリの利用者とLINEの友だちをスプレッドシート上で手作業で照合しタグを付けていた。

会員が増えるにつれてこの照合だけで月に約120時間かかっていた。

1. 会員情報とLINE IDをAPI連携で自動でひも付けた
2. LINE登録を条件にしたキャンペーンで連携を促した
3. アプリの行動データをLINE側へ取り込んだ
4. 提出が0回の人だけに応援メッセージを送る
5. 1to1チャットで顧客情報を見ながら答える

月120時間かかっていたタグ付けと顧客管理の工数がほぼゼロになり、LINE登録者の約9割がID連携済みになった。

空いた時間を配信の見直しに回した結果、有料転換率が上がり解約率も下がった。

夜間や休日に内見の問い合わせが集中し、少人数の体制では受けきれなかった。

反響を逃すと物件が他社へ流れるため、通知が来るたびにPCを開いて対応していた。

1. KUZENを入れて流入元の広告から物件情報を送り分ける
2. 内見の受付を友だち追加直後の初回アンケートに置き換えた
3. 希望条件やエリアの回答をSalesforceへ自動で入れる
4. アンケート回答を受付完了の必須ステップにした
5. GCLIDを保存しGoogle広告へ返す仕組みを組んだ

1件あたり1〜2時間かかっていた対応が平均約30分になり、月約30時間の工数が減った。

手作業の転記と聞き漏れが無くなり、内見希望者のアンケート回答率はほぼ100%を保っている。

新サービスの立ち上げでドライバーを一気に集める必要があった。

運転中でPCを開かない相手には従来のやり方が届かず、自前のLINE運用も手順が固まらないまま管理の手間が増えていた。

1. LINE公式アカウントの拡張ツールKUZENを入れた
2. 人材紹介システムのJOB階層とリアルタイムでつないだ
3. 希望の職種とエリアを選ぶと募集中の求人だけ表示する
4. 面談希望時間の聞き方をボタン選択に変えた
5. シナリオを作り直しABテストを続けて直している

有効エントリー数が導入前の2.6倍になった。

電話がつながる割合が上がって面談実施率は2倍になり、内定承諾のCPAは求人媒体の1/2・Web広告の1/4に収まった。

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

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

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固定という制限はあるが、翻訳や要約なら実用になると分かった。

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

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

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

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%減った。

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

宿泊予約センターには長年ためた返信テンプレートが5,000件以上あり、ブランドや施設ごとの階層で管理されていた。

ベテランはすぐ目的の文面を出せる一方、新人はどこにあるか分からず返信に時間がかかっていた。

1. オペレーター支援ツールを使う人だけのユーザー単位契約で小さく始めた
2. 5,000件以上のテンプレートを絞り込みグループ分けとタグ付けをした
3. 別のチームが返信文の自動生成のプロンプトを試し精度を上げた
4. 生成文は担当者と上長のダブルチェックで確認してから送る
5. 自動校閲機能で日本語の表記ミスも確認する

2024年4月入社の新人4名が早い段階でメール業務を始め、すでにベテランを超える件数の問い合わせに対応している。

返信文の自動生成は正答率80%を目安にブランド単位で広げ、現時点で3ブランドまで見通しが立った。

電話とメールだけの対応ではIPO銘柄が出たときの問い合わせ急増をさばききれず、夜間や休日の即答もできなかった。

口座開設の手続きでつまずいた顧客が他社に流れる心配もあった。

1. KARTEの画面にチャット窓を出しKARAKURIを回答エンジンとしてつなぐ
2. 2018年8月に試験導入し口座開設のサポートから始める
3. 口座開設に詳しい4人で専任チームを作る
4. 既存FAQとオペレーターの質問を会話カードにする
5. 公開後も会話カードを足したり直したりして育てる

質問は約27,000件たまり、回答率は80％まで上がった。

19〜23時のメール問い合わせが減り、4人体制だった常時待機はオペレーター2名になって社員は育成や他チームの支援に回れるようになった。

台風や地震で運休や欠航が起きると、振替や取消料についての問い合わせが一度に集中した。

担当者は複数の業務システムを見比べて判断するため回答に時間がかかり、待たされる客が積み上がっていた。

1. Web予約者向けメッセージボックスの返信を担うAIエージェントを作った
2. 問い合わせ内容と予約情報の読み取りと返信文案の作成をAIに任せた
3. 基幹システムの画面操作はRPAに任せた
4. 運休や欠航の照会と取消料免除の判定は業務ロジックAPIに切り出した
5. 人は送信前の最後の確認と送信だけを行った

2024年8月の台風10号の問い合わせ2,648件を使った机上検証で、1人あたりの処理は24件／日から101件／日になった。

返信テンプレートの選定は正解率98.5%で、具体情報の誤りは1,946件中0件だった。

サービス統合にともなう口座の初期設定について電話とメールの問い合わせが集中し、サポート窓口が回らなくなった。

オペレーターの研修に2カ月かかるため増員も難しかった。

1. 問い合わせページを刷新しチャットボットと検索FAQを設置する
2. 毎朝チャットのログを人が見てトレーニングを重ねる
3. 1つの回答に想定される質問の言い回しを大量に登録する
4. ChatGPTと連携し質問パターンを自動生成して言い回しを増やす
5. 確認事項が多い依頼はフォームで受け専任担当が対応する

リリースの翌月に7,000件、翌々月には1万件を超える対応となり、直近は2万件を超えた。

回答率は90%超、満足率は60%超になり、電話の受付を大きな問題なく終了できた。

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

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

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

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

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

契約件数が100万件を超えて電話が増える一方、2024年7月のホームページ刷新でパスワード要件を厳しくしたところログイン関連の入電が一時2〜3倍になった。

従来のシナリオ型ボイスボットは対応できる範囲が狭く、途中で話しかけられると会話が崩れた。

1. マイページのログイン問い合わせを音声AIに直接つなぐ設計にした
2. chatbotで積み上げた質問と回答がセットの会話カードを回答のもとに使った
3. 案内してよい内容だけをAIに話させた
4. 5社のデモを比べ会話の滑らかさで選んだ
5. 解決率と離脱の場所をデータで見て話し方の違和感を直した

営業時間18時を過ぎてもAIが案内する窓口ができ、これまで営業時間外の案内で終わっていた問い合わせが自分で解決できるようになった。

導入初期の解決率は約3割だった。

エスカレーションは約2割で離脱は約5割。

2026年5月時点でAI対応への苦情は0件だった。

コード量を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件テストを落とした。

オンライン資格講座スタディングの受講生が増え、問い合わせも同時に増えていた。

以前使っていた選択肢を選ぶ形のチャットボットでは疑問が解決しきらず、レポートや分析の形も自社に合わなかった。

1. 一問一答で答えるチャットボットに乗り換える
2. 管理画面の使いやすさとFAQの直しやすさで選ぶ
3. 30を超える講座ごとに起動メッセージを変えて出す
4. 毎日25件示される優先の問い合わせを担当者が直す
5. 迷う内容は週1回の打ち合わせで決める

導入前後を比べると、前年比で毎月約15%の問い合わせが減った。

本当に人の対応が必要な相手に時間を回せるようになり、問い合わせるほどでもない潜在的な疑問も見えてきた。

自社ECと楽天やAmazonなど複数モールから届く問い合わせが多く、対応に時間の大半を取られていた。

品質向上やVOCの取り組みが後回しになり、CSチームの成長が止まりかけていた。

1. 問い合わせデータの分類を生成AIに任せた
2. タグ付けの条件を後から変えられるようにした
3. 全テキスト対応をAIが評価する仕組みを作った
4. 良い点と直す点を翌日までにメンバーへ返した
5. 人は分析とフィードバックに回した

手作業のタグ付けがなくなりオペレーターの負担が軽くなった。

月に1〜2回、数件だけだった品質チェックは毎日全ての対応を翌日までに評価できるようになり、3ヶ月後や半年後を見据えた計画を立てる余裕が生まれた。

アイデアはあったが小説の書き方が分からず、てにをはや句読点の打ち方、一人称と三人称の使い分けにも自信がなかった。

1. 作品のコンセプトと筋書きをざっくり自分で書き出す
2. 書き出したものをChatGPTに渡し本文の形にしてもらう
3. 上がってきた文章を読み気になる部分を自分で直す
4. ChatGPTから直した方がいいと指摘された箇所は受け入れる

書き方を知らないままでもシリーズの連載を始められ、初期の作品はAIが書いた文章がもとになっている。

読み返すと初期作品は一文が長いものが目立つ。

自作のタスク管理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ではなく網羅を求める指示の書き方だと分かった。

電話応対はできてもメール文を書き慣れないアルバイトやパートが多く、対応できる人が限られていた。

管理者が1日50〜60件の返信を抱え、本来の管理業務に手が回らなかった。

1. Chrome拡張のKARAKURI assistをメール画面から呼び出す
2. 伝えたい内容や対応方針を箇条書きで入力する
3. 取扱説明書やFAQの記述を貼り付けて返信文を作らせる
4. ボタンで丁寧さや文字数を選ぶ
5. 出てきた文をオペレーターが確かめてから送る

文章を考える手間がなくなり、1件あたり少なくとも5分短くなった。

客からのお礼のメールが増え、オペレーターの不安や負担も小さくなった。

定期で走るはずの処理が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. 検証は読み取り専用にしてコミットは人間が行う

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

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

駅の無人化が進んで対面案内が減り、忘れ物や切符の買い方の問い合わせがお客さまセンターに集まって放棄呼が出ていた。

2011年に作った公式サイトは情報を足し続けて分かりにくくなり、旧FAQシステムも操作と更新の手間が大きかった。

1. 公式サイトを作り直し別ドメインの観光情報をまとめた
2. FAQをAIが学習を助けるsmartFAQに入れ替えて公開した
3. 大量に来る決まった質問は定型回答のチャットボットで返す
4. ばらつく質問はサイトを探して答えるAIに任せた
5. 多言語ページにもAI回答を置きサイト修正で追従させた

リリースから約1ヶ月で放棄呼の割合が約2分の1に減り、FAQの稼働率は旧システムの数倍になった。

交通系ICカードやQR乗車券に関する電話はほとんど来なくなり、多言語FAQの個別更新も要らなくなった。

新NISAの開始でファンドに関する問い合わせが増えると見込まれたが、従来のFAQはAIが入っておらず探しにくく更新もしにくかった。

電話とフォーム中心の体制では、投資初心者から経験者まで幅広い層に正確で分かりやすく答えるのが難しかった。

1. 検索性と更新性を重視しFAQ基盤を入れ替えた
2. キーワードのサジェストを入れFAQ構成を組み直した
3. 同じナレッジを使うチャットボットを追加した
4. 会話ログからページごとの要望を読み取った
5. 検索されなかった言葉を毎日拾い想定質問を足した

FAQのページ閲覧数は導入前と比べて約1.5倍になった。

検索された言葉が見えるようになり、ほぼ毎月新しいコンテンツを足す改善の流れが定着した。

配送状況や輸入可否、通関ルールなど一件ごとに事情が違う問い合わせが多く、決まった回答しか返せない従来のボットと社内の商品データを別々に更新する手間がかかっていた。

マニュアルは複雑で目的の記述にたどり着きにくく、担当者が自作した手順書に頼る属人化も進んでいた。

1. 管理者と現場担当5名ほどで2か月のトライアルを行った
2. 仮のデータを入れて応答の出方を確かめた
3. マニュアルやルールをナレッジとして登録した
4. 過去のエスカレーション事例をQ&Aの形に直して入れた
5. テンプレートや文例を100件以上集め精査して一部を登録した

チーム約20名が利用し、分散していたマニュアルやルールが集約されて調べる場所が定まり、判断のスピードが上がった。

頻発していたエスカレーションの一部は担当者が自分で解決できるようになり、回答への不安も和らいだ。

市民からの電話が月12万件に達し、国の調査などがあるたびに専用窓口を用意する必要もあって職員の負担が重かった。

各課が持つFAQは粒度がばらばらで更新漏れも多く、担当部署が変わると誰も手入れしないFAQが残って誤った案内につながる心配があった。

1. 対話型AIエージェントを市民向け問い合わせ対応に置く
2. FAQを作り直さず公式サイトの記事とPDFを回答のもとにする
3. あいまいな質問は聞き返し機能で税や料金の種類まで絞り込む
4. 各課が担当ページを最新に保ち回答の正しさを保つ
5. 導入前に個人情報を入力しないなどのガイドラインを職員に示す

FAQを個別に作って直し続ける運用をやめ、公式サイトの更新がそのまま回答の質につながる形になった。

電話が苦手な人や時間外に調べたい人が自分で解決できる窓口が加わり、将来は対面と電話とチャットを組み合わせた総合コンタクトセンターを目指す。

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

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

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

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

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

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

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

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

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

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

2,000行を超える商品データを熟練の担当者が手書きのマニュアルや経験で捌いており、辞めると情報が消えてしまう状態だった。

従来のシナリオ型チャットボットは作り込みと運用の手間が重く、担当者の負担も大きかった。

1. 新規事業の問い合わせ窓口にサイトを読んで回答するGeNを置いた
2. KARAKURI assistに工場の対策報告書をそのまま入れた
3. 決めた項目で箇条書きに整理するよう指示を出した
4. 整理された原因と対策をもとに担当者が詫び状に書き直した
5. 月1〜2回の壁打ち会で同じお題を入れ合い指示の書き方を共有した

技術者向けに書かれた報告書の読み解きと詫び状の作成が、30分から5〜10分で済むようになった。

問い合わせ件数の削減ではなく顧客体験を重視する方針で、少人数でも対応の質を保てる体制になった。

アプリ開発は素人で、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字の記録としてまとめた。

人材派遣の時給相場は動きが早く、数円の差が提案や利益に響くため最新の情報をすぐつかむ仕組みがなかった。

提案の中身も経験や知識で差が出やすく、慣れないうちは組み立てに時間がかかり内容もぼやけていた。

1. GeNで営業向けツール「提案くん」を作る
2. 顧客からの相談内容と背景を入力する
3. AIから返る確認点や追加質問に答えて提案の形にする
4. プロンプトで自社の考え方と情報ソースを指定する
5. 同じ作りで時給調査や募集原稿作成のツールも用意した

提案準備にかかる時間が縮み、検討段階での迷いも減った。

提案が個人の経験頼みでなくなり、他部署からも使いたいという声が出てAIを業務に組み込む動きが社内に広がった。

スキマバイトの利用が急に伸び、繁忙期には問い合わせが平均で3割ほど増えるのに人員は増やせなかった。

前に使っていたチャットボットでは、ユーザーが自分で悩みを解決できる状態に届かなかった。

1. 10社近くを比べローデータをすぐ落とせる点を最優先に選んだ
2. 専任グループがFAQとチャットボットの中身を保守する
3. 文章をくだけた言い回しにそろえ言い方の指針を統一する
4. どこに何を書くか構成を決め読み方を迷わせない
5. リリース直後は回答率を見て次に精度向上へ進む

必要なときに生のデータをすぐ取り出せるようになり、問い合わせの中身と回答の結果をもとに改善を回せるようになった。

有人チャットやCRMともつながり、自動で答えられる範囲を広げる土台ができた。

一次対応を外部の委託先に任せていたが、オペレーターごとに参照する情報源が違い回答内容に差が出ていた。

以前の問い合わせツールはタイトルでしか検索できず、古い情報のまま案内してしまうこともあった。

1. オペレーターの手元にナレッジを出すツールを入れた
2. 複数の言葉で引っかかるようタグを付けて登録した
3. ほぼすべてのナレッジに過去の対応事例を載せた
4. 答えにくい問い合わせは生成AIの文案を参考に書き直す
5. 運用1〜2か月後に使いにくい点を聞き中身を直す

参照するナレッジを取り違えて誤った案内をするミスがゼロ件になった。

委託先からは検索しやすくなったという声が多く出た。

問い合わせ件数やエスカレーション数は経過観察中。

Pontaは提携社や関連サービスが多く同じ質問でも状況によって答えが変わるため、旧FAQでは似た回答ばかり出て利用者が正解にたどりつけなかった。

更新にも専門的な作業が必要で、少人数の担当者では改善の頻度を上げられなかった。

1. Q&Aデータを一箇所に登録しFAQを自動生成する形にした
2. チャットボットで条件分岐を使い利用サービスや状況を聞き返す
3. AI提示の25件と担当者選定の25件で毎日50件以上を学習させる
4. 低評価のやり取りをたどりQ&Aのつなぎ方を直す
5. 集まった質問を分析し社内担当へ優先度を上げてもらう

2023年6月の本番導入から数か月後の利用者アンケートで、解決率が導入前より5.9ポイント改善した。

更新作業を複数人で分けられるようになり担当者の負担も軽くなった。

約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時間の対応がかなった。

顧客対応を自社で行うため商品好きな未経験者を採用したが、文章作成に手間取り応対の質が落ちることを心配していた。

複数のモールごとに返信の定型文を用意するのも手間だった。

1. ブラウザ拡張のオペレーター支援ツールを入れる
2. どの窓口でも同じ画面から定型文を呼び出せるようにする
3. 定型文をブロック単位で並び替えチャットとメール返信に使う
4. レビュー返信は指示文から生成AIに下書きを作らせ手直しして送る
5. 繁忙期前に研修へ時間をかけ新人に操作を覚えてもらう

メール対応の1日平均は25件から30件になり、誤字脱字による差し戻しは23%から0.36%に減った。

新人のOJT期間は40〜45日程度から15日になり、レビュー返信1件の作成時間は半分になった。

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

クラウドの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行も見つかった。

スキャンした領収書のフォルダをそのままChatGPTに渡してチェックリストを作らせたところ、紙で受け取った領収書のスキャン画像まで電子取引データとして扱われていた。

フォルダに入っているものはすべて対象という前提でAIが判断していた。

1. ファイル名の先頭に電子か紙かの区分を手作業で書き込む
2. ChatGPTに電子_のファイルだけでチェックリストを作らせる
3. 出てきたリストの件数をフォルダ側の件数と照らす
4. タイムスタンプの付与期限など日付は自分で数え直す

区分を先に決めてから任せる順番に変えたことで、対象外の書類が紛れることはなくなった。

今回は38件が電子取引のデータ、残る12件は紙をスキャンしたもので対象外という分かれ方だった。

月次の報告でこの話を共有し、上司から制度対応の精度を評価された。

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

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

1枚のイラストを作るのは手軽にできる一方で、同じキャラクターで場面を続けて描くと構図や色が似てしまい、ばらばらの絵の寄せ集めになってしまう。

1. 白うさぎを追う最初の1枚を作り次の場面を自分で考える
2. うさぎ穴から巨大化やキノコの森へと場面を順に足す
3. チェシャ猫やお茶会や女王やカードの嵐や夕暮れまで生成する
4. 毎回アングルと配色を変え巨大化は見上げる構図にする
5. 全場面を1枚にまとめたタイトル画像を作る

9枚のイラストが同じ世界の続きとして見えるようになり、最後に9場面を1枚にまとめたタイトル画像を作ったことで、絵の集まりではなく一つの物語として並んだ。

面接官3人が別々に付けたスコアをChatGPTにまとめさせたところ、合計点の順位が自分の感覚とずれ、一番良かったはずの候補者が2位になっていた。

点数の付け方が厳しい面接官と甘い面接官の差が、そのまま平均されていた。

1. 過去の選考記録から面接官ごとの平均点を算出する
2. 依頼文の冒頭にA3.1点B4.2点C3.6点と書き添える
3. 各面接官の平均からの離れ具合を先に計算させる
4. 偏差値に直して3人の評価を比べるよう指示を固定する
5. 出力された順位を元の単純合計と自分の目で照合する

基準となる平均を先に伝える流れにしてから、厳しさの違いを無視して足し合わせる間違いは起きなくなった。

偏差値に直すと候補者1人の位置が単純合計のときと入れ替わり、採点者ごとの偏りを会議の前に言葉で示せるようになったと人事部長から評価された。

書籍の全章分の原稿をひとつのファイルにまとめる作業を手でやると、コピーと改行の直し、目次と見出しの確認で時間がかかっていた。

1. 章ごとに分かれた原稿ファイルをすべてAIに渡す
2. 順序通りにきれいにひとつへまとめてほしいと言葉で頼む
3. 出てきた統合原稿の章の並びと見出しを目で確かめる
4. 自分は内容や読者への伝え方を考える時間に回す

およそ7万3千文字の統合原稿が数秒で仕上がった。

以前は同じ作業に丸一日かかっていた。

同じテンプレートからブラウザのプレビューとサーバの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人分の余力が生まれた。

入院説明など患者への同じ説明を職員が何度も繰り返しており、時間がかかっていた。

タブレットで動画を見せる取り組みはあったが、動画を作って配る仕組みが整っていなかった。

1. 院内のPowerPoint資料をVideoStepに読み込ませる
2. AIに中身を整理させて説明の台本を作らせる
3. 字幕と音声付き動画を担当者が言い回しと順番を直して仕上げる
4. パソコンの操作手順は画面録画で残し手順動画にする
5. 動画をURLとQRコードで配り患者が自分のタイミングで見られるようにした

リハビリテーション科と栄養管理課で動画が使われ始め、患者への説明を動画で補える形になった。

今後は病棟の看護師や知多半島りんくう病院にも広げる予定。

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. 他の人が公開する文字合成プロンプトをChatGPTに読み込ませる
2. 自分のアバターから派生したイラストを渡す
3. 文字数を減らして顔を大きくするよう指示する
4. 5文字までは1文字に1人、超えると1枚絵になると確かめる
5. できた静止画をPollo AIのSeedance 2.0 Miniで動画にする

「スキ」という飾り文字が短時間ででき、記事の最後に置く画像として使えた。

動画にすると文字で切れていた部分が補われ、髪型や背景が変わって秋らしい別のキャラになった。