# AI活 (ai-katsu) — Full Article Corpus > 公開記事の本文を Markdown で結合したものです。最大 200 件、新着順。 Source: https://ai-katsu.jp --- ## 動画URLから記事下書きまで約5分｜AIに「型」を教えて品質を固定する - URL: https://ai-katsu.jp/articles/interview-article-automation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-07-15T00:00:00+00:00 - Models: Claude Code - Tools: YouTube Data API - Tasks: 資料作成・デザイン, 業務プロジェクト - Domain: マーケティング > インタビュー動画のURLを渡すだけで記事下書きが完成する仕組みを作り、2〜3時間の作業を約5分にしました。効いたのは自動化より型の事前定義で、過去記事4本の文体学習と採点表による自己採点・最大2回の自動リライトで品質を固定しています。 記事制作をAIに任せると、それらしい文章は返ってきても**自社のトーンから外れた、のっぺりした出力**になりがちです。原因は生成能力ではなく、**「型」を渡していないこと**にあります。 この検証では、**インタビュー動画のURLを渡すだけで note 記事の下書きが完成する仕組みを構築し、2〜3時間かかっていた作業を約5分にしました。**要点は自動化そのものより、AIに文体・構成・採点基準を先に教えた部分にあります。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年7月 | | やりたかったこと | 卒業生インタビュー動画から記事下書きを作る工程を自動化する | | 人の作業 | **動画URLを渡すことと、公開前の最終確認だけ** | | 所要時間 | **約2〜3時間 → 約5分** | | 出力 | **約3,400字のQ&A形式インタビュー記事**の下書き | | 品質担保 | **採点表（ルーブリック）でAIが自己採点し、最大2回まで自動で作り直す** | | 自動化しない部分 | **公開ボタンは必ず人が中身を確認してから押す** | > 本記事は、グループ会社である**株式会社バイテックでの検証記録**をもとに、当社の検証レポート形式で再構成したものです。数値・工程・つまずいた内容は、検証時の記録をそのまま記載しています。原文は[note の公開記事](https://note.com/makun_bytech/n/nb8c157095cf0)（2026年7月15日公開）をご覧ください。 ## 結論：効いたのは自動化ではなく「型の事前定義」 単に「記事を書いて」と頼むだけでは、自社のトーンとかけ離れた文章が返ってきます。**この仕組みで最重要なのは、AIに自社らしさを覚えさせた部分です。** | 渡したもの | 内容 | | --- | --- | | **お手本** | **過去のnote記事4本**を読ませて文体を学習させる | | **構成のルール** | プロフィール → Before/After → きっかけ → 決断 → 学習 → 成果 → メッセージ → CTA | | **文体のルール** | インタビュー形式／話し言葉をそのまま引用／絵文字なし | | **禁止表現** | 「絶対に稼げる」のような断定はNG | | **採点基準** | 採点表（ルーブリック）で自己チェックさせる | **この下ごしらえがあるから、毎回ほぼ同じ品質の記事が出てきます。逆に、ここを省くと精度は出ません。**AIは察してくれないので、お手本とルールを先に渡すことが土台になります。 ## 使ったもの | 要素 | 役割 | | --- | --- | | **Claude Code** | 全体の司令塔。日本語の依頼を受けて他の道具を動かす | | **youtube-transcript-api** | YouTubeの自動字幕を取得する部品。**書き起こし作業がゼロになる** | | **過去のnote記事4本** | 文体を学習させるためのお手本 | | **採点表（ルーブリック）** | 出来上がった記事が基準を満たすかをAI自身がチェックするための基準 | **いずれも複雑なプログラムではなく、AIに「やること」「お手本」「チェック基準」を渡しているだけです。** ## 処理の流れ（6ステップ） ``` ① YouTubeのURLを渡す ← 人がやるのはここだけ ② 字幕を自動取得（文字起こし） ③ 事前に覚えさせた「型」と「文体」を適用 ④ 記事を自動生成（約3,400字・Q&A形式） ⑤ 採点表でAIが自己採点 → 基準未達なら最大2回まで自動で作り直し ⑥ note の新規作成ページに自動入力し、下書き保存 ↑ 公開ボタンは人が押す ``` ⑤では実際に、**「ポンコ」→「ポンコツ」という誤字をAI自身が発見して修正した**ケースがありました。採点項目には「タイトルに名前とベネフィットが入っているか」「文字数は範囲内か」「見出しは3つ以上あるか」「収益を断定していないか」「誤字はないか」などが含まれます。 ⑥は **Claude in Chrome**（ブラウザを操作する拡張機能）を通じて、note の新規作成ページを開き、タイトルと本文を入力して下書き保存まで行います。 ## 時間の内訳 | 工程 | 従来 | 自動化後 | | --- | --- | --- | | 字幕の取得 | 30〜60分 | **0分（自動）** | | 記事の生成・チェック | 60〜90分 | **0分（自動）** | | noteへの入力 | 15〜30分 | **0分（自動）** | | **最終確認（公開前）** | 5分 | **5分（変えない）** | | **合計** | **約2〜3時間** | **約5分** | **削減しているのは地味な作業の積み上げであり、最終確認の5分は意図的に残しています。** ## つまずいた点：ブラウザ操作の接続 最も詰まったのは⑥の note 自動入力、**Claude in Chrome の接続**でした。**「ブラウザが操作できません」と言われ続け、何度試してもエディタに文字が入らない**状態が続いています。 解決の糸口はシンプルで、**「なぜできないのか」をそのまま Claude Code に聞くこと**でした。エラーの理由を一緒に切り分けたところ解決しています。 **AIは完成品を出す道具というより、詰まりを一緒に外していく相手だと捉えると扱いやすくなります。** ## 同じ考え方が使える作業 - **会議の録音 → 議事録の自動生成** - **顧客アンケート → SNS投稿文の自動生成** - **採用面接の録画 → 候補者サマリーの自動生成** - **商品レビュー → 販売ページのコピー生成** 共通するのは**「型があって、毎回繰り返している作業」**という条件です。毎回似たような文章を手で書いている作業が該当します。 ## よくある質問 ### なぜ2〜3時間が5分になるのですか？ **字幕取得（30〜60分）・記事生成とチェック（60〜90分）・noteへの入力（15〜30分）がすべて0分になるためです。**残るのは公開前の最終確認5分だけで、ここは意図的に自動化していません。 ### AIに自社らしい文章を書かせるには？ **お手本・構成ルール・禁止表現・採点基準を先に渡します。**今回は過去記事4本で文体を学習させ、構成と禁止表現をルール化し、採点表で品質を担保しました。ここを省くと精度が出ません。 ### 品質のばらつきはどう防いでいますか？ **採点表（ルーブリック）でAI自身に採点させ、基準を満たさなければ最大2回まで自動で作り直します。**タイトルの要件・文字数・見出し数・断定表現の有無・誤字などをチェックしています。 ### 公開まで全自動にしないのはなぜですか？ **下書き保存までを自動化し、公開ボタンは必ず人が中身を確認してから押す設計にしているためです。**ここは意図的に自動化していません。 ### どんな作業から始めるとよいですか？ **「型があって、毎回繰り返している作業」を1つ探してください。**毎回似たような文章を手で書いている作業が最初の候補になります。 ## まとめ - 効いたのは自動化そのものより**「型」の事前定義**だった - 渡したのは**お手本（過去記事4本）／構成ルール／文体ルール／禁止表現／採点基準** - 処理は**URLを渡す → 字幕取得 → 型を適用 → 生成 → 自己採点 → note に下書き保存**の6ステップ - 出力は**約3,400字のQ&A形式**。基準未達なら**最大2回まで自動で作り直す** - 時間は**約2〜3時間 → 約5分**。最終確認の5分だけ残している - **公開ボタンは人が押す。**ここは自動化しない - 最大の詰まりは**ブラウザ操作の接続**。「なぜできないのか」をAIに聞いて切り分けた - 応用の条件は**「型があって、繰り返している作業」**であること 生成AIの出力品質は、モデルの能力より前に「何を基準として渡したか」で決まります。お手本と採点基準を先に用意できるかどうかが、量産に耐えるかを分けます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のコンテンツ制作へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 動画をHTMLで書く｜Premiere Pro・Remotion・HyperFramesを全部試した結論 - URL: https://ai-katsu.jp/articles/hyperframes-video-generation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-07-08T00:00:00+00:00 - Models: Claude Code - Tools: Remotion, ElevenLabs - Tasks: 資料作成・デザイン, ツール検証 - Domain: マーケティング > AIで動画を作る3方式を同一目的で比較し、HyperFramesを採用しました。約60秒の動画を縦横2本、HTMLを1行も書かずClaude Codeへの日本語指示だけで制作しています。8場面をAIが並列生成する挙動、未登場要素でレイアウトがずれる罠、字幕が自動同期しない前提までまとめています。 「AIで動画を作る」と言っても、やり方は一つではありません。編集ソフトにAIを組み込む方法、コードで組み立てる方法、コードから丸ごと生成する方法。**どれが実務で使えるのかは、実際に3つとも動かしてみないと判断できません。** この検証では、**Premiere Proプラグインの自作・Remotion・HyperFrames の3方式を同一の目的（紹介動画の制作）で試し、最終的に HyperFrames を採用しました。**約60秒の動画を縦型・横型の2本、**HTMLを1行も書かずに Claude Code への日本語指示だけ**で制作しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年7月 | | 比較対象 | **①Premiere Proプラグイン自作　②Remotion（React）　③HyperFrames** | | やりたかったこと | 編集ソフトの手作業に戻らずに、伝わる動画を量産できる状態にする | | 制作物 | 約60秒の紹介動画を**縦型（9:16）・横型（16:9）の2本** | | 結果 | **③HyperFrames を採用。**Premiere Pro のサブスクは一旦解約 | | 制作コスト | **ほぼ音声代のみ**（画面の組み立てと書き出しはローカル完結で追加料金なし） | > 本記事は、グループ会社である**株式会社バイテックでの検証記録**をもとに、当社の検証レポート形式で再構成したものです。数値・設定値・コマンド・つまずいた内容は、検証時の記録をそのまま記載しています。原文は[note の公開記事](https://note.com/makun_bytech/n/n362e4bcfdaba)（2026年7月8日公開）をご覧ください。 ## 結論：3方式は「置き換え」ではなく用途で分かれる | 方式 | 向いているケース | ハードル | | --- | --- | --- | | **①Premiere Proプラグイン** | 既存の素材・プロジェクトを活かした作り込み | プラグインの用意と設定が重く、**要所で手作業が残る** | | **②Remotion** | **テンプレートを固めて量産する運用** | Reactの知識が前提。最初のテンプレ作りに手間がかかる | | **③HyperFrames** | **単発の動画を素早く作る** | 初回の環境構築のみ | ②と③はどちらも「コードで動画」の仲間ですが、分岐点は**テンプレを固めて回すのか、1本ずつ作るのか**です。今回は後者だったため③を選んでいます。 ## HyperFrames とは：HTMLに「時間」を書き足す HyperFrames は、**HTMLで動画を組み立てるツール**です。Webページを作るのと同じHTMLに、「この文字は3秒後に出す」「この線は5秒かけて伸ばす」といった時間の指示を書き足せるようにしたもの、と捉えると分かりやすくなります。 ``` HTMLで「何を・いつ・どう動かすか」を書く ↓ その画面を1コマずつ自動でスクリーンショット ↓ コマをつなげて mp4 に書き出す（レンダリング） ``` 重要なのは、**このHTMLを書くのは Claude Code だという点です。**依頼側は「こういう動画にしてほしい」と日本語で伝えるだけで、HTMLには触れません。 ## 導入手順 ### 前提となるツール（初回のみ） | ツール | 役割 | | --- | --- | | **Node.js（v22以上）** | プログラムを動かす土台 | | **FFmpeg** | コマ画像を mp4 に束ねる変換 | **この2つのインストールが最大の関門です。**慣れていれば数分ですが、初めてだと「どこから入れるのか」でつまずきます。 ### セットアップから書き出しまで ``` # HyperFrames 一式を用意 npx hyperframes init 好きな名前 # 環境チェック npx hyperframes doctor # プレビュー npm run dev # 書き出し npm run render ``` これらのコマンドも、**Claude Code に日本語で頼めば代わりに実行されます。**ターミナルを直接触る場面は限定的でした。 ナレーションを付ける場合は、**Claude Code を fal.ai と連携させておく必要があります**（AI音声機能を呼び出すための接続）。これも初回に一度だけの作業です。 ## 制作フロー：台本から mp4 まで | ステップ | 内容 | | --- | --- | | 1\. 台本を決める | 伝えたいことを1行に絞り、要素を場面に分解する | | 2\. ナレーションを作る | AI音声に読み上げさせる。**やり直しが一瞬** | | 3\. 画面を作ってもらう | 「1場面ずつ、こういう見た目で」と日本語で依頼。Claude Code が場面ごとのHTMLを書く | | 4\. プレビューで確認 | **指定秒数の画面を静止画で一覧表示し、崩れを目視チェック** | | 5\. 書き出す | コマンド一つで mp4 化。**約60秒の動画が1分ちょっとで完了** | できあがったのは縦型（9:16・スマホ向け）と横型（16:9・YouTube／サイト埋め込み向け）の2本で、**ファイルサイズは1本5〜6MB**でした。 ## ナレーションはAI音声で作る 音声は人が録らず、すべてAIが読み上げています。 - **声の選定**：ElevenLabs の「**Sarah**」（落ち着いた女性の声）を使用 - **読ませ方**：「このセリフを、落ち着いた女性の声で読ませて」と日本語で依頼。声の方向性も言葉で指定できる - **尺の測定**：出てきた音声の秒数を測り、それを動画のタイミングの土台にする - **BGM**：最後に小さめの音量で重ねる **声と画面がズレないのは、先に音声の尺を確定させてから画面を合わせているからです。** ### 英単語の読み間違いは台本側で直す AI音声は英単語を想定外の読み方をすることがあります。「Claude Code」をそのまま渡すと「クラウド…」と読まれるケースがありました。 **対処は、エンジンを替えるのではなく台本の側で「クロードコード」とカタカナで書くことです。**読み方を教えるほうが早く確実でした。 ### 字幕は自動では同期しない 見落としやすい前提があります。**HyperFrames も Remotion も、AIが音声の中身を聞き取るわけではありません。** そのため「この声のこの瞬間に字幕を出す」は自動では起こりません。ナレーションとタイミングは**あらかじめ自分で用意しておくのが前提**です。字幕を自動で合わせたい場合は、Whisper のような文字起こしを別途用意する必要があります。 ## 60秒を8場面に分ける 約60秒を8つの場面に分割して流れを作りました。構成の要点は**1つの場面に1つのメッセージだけ**を置くことです。 **静止画を多く見せるより、「1画面＝1メッセージ」で潔く切り替えるほうが伝わります。**あれもこれも詰め込まない、という判断が結果的に効きました。 ## つまずいた3点 ### 壁①：文字が「カクッ」とずれる 文字を1つずつ順に表示させる場面で、新しい文字が出るたびに上の文字が上方向に動く現象が起きました。 原因は、**HyperFrames がまだ登場していない要素を「そこに無いもの」として扱う**ためです。登場前は場所を取らないので、次の文字が出た瞬間に詰まって全体がずれます。 対処は逆転の発想で、**最初から全要素を配置しておき、表示・非表示だけを制御する**形にしました。これで場所が先に確保され、あとから出ても他が動きません。**この修正は Claude Code に一言頼むだけで全場面に一括反映されました。** ### 壁②：要素が画面からはみ出た 横型で5段階の項目を横一列に並べたところ、**5つ目が右端で見切れていました。**静止画チェックで発見し、カードの幅と間隔を詰めて左右に余白を残すよう調整しています。 ### 壁③：文字が別の文字に重なった 下に置いたはずの補足文が、上のメイン文字に重なっていました。原因は壁①と同じ「場所の確保」が一部に効いていなかっただけで、**設定を全体に効かせたら解消**しました。 3点に共通する教訓は明快です。**書き出す前に、必ず静止画で目視チェックする。**原因の当たりさえつけば修正は一瞬ですが、当たりがつかないとここで時間を溶かします。 ## 並列生成が効く この方式で最も差が出たのが、**画面を手分けして同時に作れる**点です。 今回は8場面。人が作るなら1枚ずつ順番ですが、**Claude Code は1場面につき1体のAIを割り当てて8枚を同時並行で組み立てられます。**しかも各AIが自分の画面のスクリーンショットを撮り、正しく表示できているかを自己チェックしてから返してきます。 ①②の方式には無かった挙動で、ここが決定的な違いでした。 ## 修正コストの低さ 採用の決め手になった要素をもう2つ挙げます。 - **修正が一瞬で終わる**：たとえば「44レッスン」を「40レッスン」に直したいとき、Claude Code に「40レッスンに直して」と言うだけ。文字も配置も色も言葉で指示できる - **何本作っても品質がブレない**：HyperFrames は現在時刻や乱数を使わない前提で動くため、**指示が同じなら結果も同じ（決定論的）** 後者が効いたのは横型を作るときでした。**縦型を作ったあと、中身とナレーションはそのままにレイアウトだけ組み替える作業が非常にスムーズでした。** ## 分かっている弱点 - **感覚的な微調整は苦手**。「なんとなくオシャレに」といった指示には向かない - **モーションブラーのような表現は、After Effects や Premiere といった専用ソフトに一歩譲る** 作り込んだ映像編集が必要な場面では、従来の編集ソフトのほうが依然として強いという判断です。 ## コストと適用範囲 制作費は**ほぼ音声代のみ**でした。画面の組み立ても書き出しもローカルで完結するため、追加料金が発生しません。**アバターが話す動画でも1本数百円ほど**です。 この方式は紹介動画専用ではなく、次のような用途にも展開できます。 - **アバターが話すショート動画**：人物画像とセリフを渡すと口が動く動画になる - **画面録画の操作ガイド**：実際のWebサイトを自動操作しながら録画し、ナレーションとテロップを乗せる - **リリックビデオ**：AIで作った曲に歌詞を拍に合わせて動かす 共通するのは**ほとんどの工程がローカルで完結し、追加コストがほぼかからない**ことです。 ## よくある質問 ### プログラミングの知識は必要ですか？ **HyperFrames を使う場合は不要でした。**今回はHTMLを1行も書かず、Claude Code に日本語で指示しただけです。ただし Remotion を選ぶ場合は React の知識が前提になります。 ### 導入で一番つまずくのはどこですか？ **Node.js（v22以上）と FFmpeg のインストールです。**慣れていれば数分ですが、初めてだとここで止まります。セットアップさえ済めば、あとは日本語で頼むだけになります。 ### Remotion と HyperFrames はどちらを選ぶべきですか？ **単発の動画を素早く作るなら HyperFrames、テンプレートを固めて量産するなら Remotion です。**SNS動画を毎日回すような運用では Remotion のほうが向く場面もあります（最初のテンプレ作りには相応の手間がかかります）。 ### 字幕は自動で音声に合いますか？ **合いません。**HyperFrames も Remotion も音声の中身を聞き取らないため、ナレーションとタイミングは事前に用意する必要があります。自動同期させたい場合は Whisper のような文字起こしを別途組み合わせます。 ### 編集ソフトは不要になりますか？ **用途によります。**今回は Premiere Pro のサブスクを一旦解約しましたが、モーションブラーのような表現や作り込んだ映像編集が必要になれば専用ソフトのほうが適しています。 ## まとめ - 3方式は置き換え関係ではなく**用途で分かれる**。単発なら HyperFrames、量産なら Remotion、作り込みなら編集ソフト - HyperFrames は**HTMLに時間の指示を書き、1コマずつスクショして mp4 に束ねる**仕組み - 前提ツールは **Node.js（v22以上）と FFmpeg**。ここが唯一の関門 - 約60秒の動画が**1分ちょっとで書き出し**、ファイルは1本5〜6MB - **未登場の要素は場所を取らない**ためレイアウトがずれる。全要素を配置して表示だけ制御する - **書き出す前に静止画で目視チェック**する。原因の当たりがつけば修正は一瞬 - 音声の中身は解析されないので、**ナレーションと尺は先に確定させる** - AI音声の英単語の読み間違いは**台本側をカタカナにして解決**する - **8場面を8体のAIが並列で組み立て、各自がスクショで自己チェック**する挙動が他方式との決定的な差 - 制作費は**ほぼ音声代のみ**。ローカル完結で追加料金が出ない コードで動画を作る方式の価値は、表現力よりも「直しやすさ」と「ブレなさ」に出ます。1本目より2本目、2本目より3本目が速くなる構造かどうかが、量産の可否を決めます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のコンテンツ制作へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## GASはスクリプトIDを渡すだけ｜コードを書かずに自動化を組んだ手順 - URL: https://ai-katsu.jp/articles/gas-script-id-claude-code - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-07-05T00:00:00+00:00 - Models: Claude Code - Tools: Google Apps Script, Google Workspace, Discord - Tasks: 業務自動化・ワークフロー, ツール検証 - Domain: バックオフィス > スクリプトIDをClaude Codeに渡すだけで、GASの取得・実装・反映まで自動で進みます。プログラミング未経験の担当者がコードを1行も書かずに、フォーム回答のDiscord通知や月次KPI集計を構築しました。最初から全部作ろうとして失敗した経緯も記載しています。 GAS（Google Apps Script）は無料で強力な自動化の仕組みですが、**入口でコードと用語に阻まれて手が止まる**ケースが多くあります。「便利なのは分かっている、けれど自分には無理」で止まりやすい領域です。 この検証では、**Claude Code に「スクリプトID」を渡すだけで、コードを1行も書かずにGASの自動化を組めることを確認しました。**実装したのはプログラミング未経験の担当者です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年7月 | | やりたかったこと | コードが書けなくても、GASによる業務自動化を組める状態にする | | 手順 | **スクリプトIDをコピーして Claude Code に渡すだけ** | | Claude Code の担当 | **GASの中身を自動取得 → コードを書く → 反映まで** | | 実装者 | プログラミング未経験。コードは1行も書いていない | | 前提 | Claude Code と Google の接続設定を一度だけ済ませておくこと | > 本記事は、グループ会社である**株式会社バイテックでの検証記録**をもとに、当社の検証レポート形式で再構成したものです。手順・つまずいた内容は、検証時の記録をそのまま記載しています。原文は[note の公開記事](https://note.com/makun_bytech/n/n8b913bde54c4)（2026年7月5日公開）をご覧ください。 ## 結論：渡すのはスクリプトID1つ ``` 【従来】 「GAS やり方」で検索 → コードがずらりと並ぶ → 関数・トリガーといった用語で迷子 → 手が止まる 【今回】 スクリプトIDをコピー → Claude Code に渡す → Claude Code が中身を読み取り、コードを書き、反映する → 人がやるのは「こうしたい」を日本語で言うことだけ ``` **Claude Code は、渡されたGASの中身を自動で読み取り、依頼に合わせてコードを書き・直し・反映まで行います。**エラーが出た場合も「なぜ動かないのか」を聞けば、原因の切り分けから対応まで進みます。 ## そもそもGASとは **GAS（Google Apps Script）は、Googleが無料で用意している自動化の仕組みです。**スプレッドシート・Gmail・カレンダー・フォームといったGoogleのサービスを、決めた条件で自動的に動かせます。 - フォームに回答が入ったら、自動でDiscordに通知 - 毎月1日に、複数シートの数字を自動で集計 - 特定のメールが来たら、管理表のステータスを自動更新 人が手でやっていた作業を裏で処理する仕組みで、**無料かつ強力**です。問題は常に「その先」——実装の入口にありました。 ## 実際の手順 | 手順 | 操作 | | --- | --- | | **1\. スクリプトを開く** | 自動化したいスプレッドシートを開き、メニューの**「拡張機能」→「Apps Script」** | | **2\. スクリプトIDをコピー** | 開いた画面の左にある**「⚙️（設定）」から「スクリプトID」**をコピー | | **3\. Claude Code に渡す** | **「スクリプトID：〇〇 のGASに、△△する機能を追加して」**と依頼する | スクリプトIDは、そのGASの所在を示す識別子です。これを渡すと、あとは Claude Code が取得・実装・反映まで進めます。 なお、**Claude Code と Google をつなぐ初回の設定は別途必要です。**そこを一度済ませれば、以降は「スクリプトIDを渡すだけ」で回ります。 ## 実際に組めた自動化 | 自動化 | 内容 | | --- | --- | | **フォーム回答 → Discord通知** | 申し込みや問い合わせが入ったら、すぐチームに共有 | | **月次KPIの自動集計** | 複数シートに散らばった数字を、毎月まとめて1枚に | | **メール監視 → 管理表を自動更新** | 特定のメールが来たら、ステータスを自動で書き換え | いずれも以前は人が手で行っていた作業です。**コードを書けない担当者が、日本語の依頼だけで組んでいます。** ## GAS以外にも同じ考え方が効く 「渡すだけ・依頼するだけ」という進め方は、GASに限りません。 - **Gmail**：メールの自動仕分け・下書き作成 - **ドキュメント**：議事録・報告書のテンプレート差し込み - **ドライブ／フォーム**：ファイル整理・回答の自動集計 一度入口を越えると、**「これも自動化できるのでは」という発見が連鎖します。** ## つまずいた点：最初から欲張った 最初から順調だったわけではありません。**やりがちだったのは、最初から全部いっぺんに作ろうとすることでした。**あれもこれもと詰め込んだ結果、動かずに終わっています。 抜け出すコツは明快でした。**いちばん面倒な、たった1つから始めることです。** 小さく1個動かすと、「自分でもシステムが作れる」が知識ではなく体感に変わります。**そこから対象範囲が広がっていきました。** ## よくある質問 ### プログラミングの知識は必要ですか？ **不要でした。**今回はコードを1行も書いていません。スクリプトIDを渡し、やりたいことを日本語で伝えるだけです。 ### スクリプトIDはどこにありますか？ **スプレッドシートの「拡張機能」→「Apps Script」で開いた画面の、左側にある「⚙️（設定）」の中です。**そこから「スクリプトID」をコピーします。 ### 事前に必要な準備はありますか？ **Claude Code と Google をつなぐ初回の接続設定が必要です。**これを一度済ませれば、以降は「スクリプトIDを渡すだけ」で運用できます。 ### エラーが出たらどうしますか？ **そのまま Claude Code に「なぜ動かないのか」を聞きます。**原因の切り分けから修正まで一緒に進みます。エラーメッセージの意味が分からなくても止まりません。 ### 最初に何から手を付けるべきですか？ **いちばん面倒な作業を1つだけ選んでください。**最初から全部を作ろうとすると動かずに終わります。1個動かすと感覚が変わり、そこから広げられます。 ## まとめ - GASの壁は**コードそのものではなく、入口の用語と情報量**にあった - 渡すのは**スクリプトID1つ**。取得・実装・反映は Claude Code が担う - スクリプトIDは**「拡張機能」→「Apps Script」→「⚙️設定」**から取得する - **Claude Code と Google の接続設定だけは初回に必要** - 実際に組めたのは**フォーム回答→Discord通知／月次KPI集計／メール監視→管理表更新** - 同じ考え方が**Gmail・ドキュメント・ドライブ・フォーム**にも効く - 失敗の原因は**最初から全部作ろうとしたこと**。いちばん面倒な1つから始める 自動化に必要なのはコードを書く力ではなく、自動化したい作業を特定して言葉にする力です。入口さえ越えれば、対象を広げるコストは急速に下がります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のバックオフィス業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## スプレッドシートをAIに直接つなぐ｜サービスアカウントでコピペ往復をなくす手順 - URL: https://ai-katsu.jp/articles/claude-code-sheets-service-account - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-07-04T00:00:00+00:00 - Models: Claude Code - Tools: Google Workspace, Google Cloud, Discord - Tasks: 業務自動化・ワークフロー, ツール検証 - Domain: バックオフィス > サービスアカウントにシートを共有するだけで、Claude Codeがスプレッドシートを直接読み書きできます。設定は15〜20分・初回のみ。Google Cloudでの手順6ステップ、権限エラーの切り分け、ファイル移動で作業履歴を失った事故まで記録しました。 AIにスプレッドシートの作業を頼むとき、**表をコピーして貼り付け、返ってきた結果をまた貼り戻す**という往復が発生します。AIは賢いのに、受け渡しだけが手作業として残る状態です。 この検証では、**Claude Code にスプレッドシートを直接読み書きさせることで、このコピペの往復をなくしました。**難しいプログラムは書かず、**サービスアカウントにシートを共有するだけ**で成立します。設定の所要時間は15〜20分です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年7月 | | やりたかったこと | スプレッドシートとAIの間で発生する「コピペの往復」をなくす | | 仕組み | **サービスアカウント（プログラム専用のGoogleアカウント）にシートを共有する** | | 設定時間 | **15〜20分**（初回のみ。以降はシートを共有するだけ） | | 結果 | 「A列の名前を一覧にして」など**日本語の指示だけで完結** | | 応用範囲 | 同じ許可設定を土台に、ドキュメント・Gmail・Drive・フォームへ展開可能 | > 本記事は、グループ会社である**株式会社バイテックでの検証記録**をもとに、当社の検証レポート形式で再構成したものです。設定手順・つまずいた内容は、検証時の記録をそのまま記載しています。原文は[note の公開記事](https://note.com/makun_bytech/n/n0dc3c334d847)（2026年7月4日公開）をご覧ください。 ## 結論：やっていることは「鍵を1本渡す」だけ 「直接つなぐ」と聞くと複雑に思えますが、考え方は単純です。 **サービスアカウントとは、人間ではなくプログラム専用のGoogleアカウントのことです。**普段シートを誰かと共有するときに相手のメールアドレスを追加するのと同じ手順で、このプログラム用アカウントにシートを共有すると、Claude Code がそのシートを読み書きできるようになります。 ``` 【従来】 スプレッドシート → 手でコピー → AIチャットに貼付 → 結果を手で貼り戻す 【直結後】 スプレッドシート ←→ Claude Code ↑ サービスアカウントに「編集者」で共有しておくだけ ``` やることは2つだけです。 - Google側で**プログラム用のアカウント（サービスアカウント）を1つ用意する** - 使いたいシートを、そのアカウントと**編集者権限で共有する** ## 設定手順 | STEP | 操作 | | --- | --- | | **1** | Google Cloud にアクセスし、普段シートを使っているGoogleアカウントでログイン。**新しいプロジェクトを1つ作成** | | **2** | 「APIとサービス」→「ライブラリ」→ **Google Sheets API** を検索して**有効にする** | | **3** | 「APIとサービス」→「認証情報」→「認証情報を作成」→「サービスアカウント」。名前は任意（例：`claude-sheets`）、**ロールは「編集者」** | | **4** | 作成したサービスアカウントの「鍵」タブ →「キーを追加」→「新しい鍵を作成」→ **JSON** を選択。ダウンロードしたJSONをClaudeのフォルダに保存 | | **5** | 対象のシートを開き、「共有」→ STEP 3のメールアドレスを入力 → **権限は「編集者」**→ 送信 | | **6** | Claude Code のチャットで設定を依頼。**設定ファイルへの追記は自動**。完了後に **Claude Code を再起動** | STEP 3で発行されるメールアドレスは `claude-sheets@プロジェクトID.iam.gserviceaccount.com` の形式です。これが、あとでシートを共有する相手になります。 **JSONファイルは鍵そのものなので、他人に渡らないよう管理してください。** **新しいシートを追加したいときは STEP 5 だけを繰り返せば済みます。**STEP 1〜4は最初の一回だけです。 ## 使い方は日本語で伝えるだけ 設定後は、次のような依頼がそのまま通ります。 - 「このスプレッドシートのA列に入っている名前を読み取って、一覧にして」 - 「"申込後ステータス管理"タブのB列に、今日の日付を追記して」 - 「この表を集計して、多い順に並べて」 **コピーも貼り付けも、範囲選択も不要です。**関数を覚える必要もありません。 ## つまずいたときの切り分け | 症状 | 確認するところ | | --- | --- | | **「権限がありません」** | **STEP 5の共有で、メールアドレスが正しく入っているか** | | 「ファイルが見つかりません」 | JSONファイルがClaudeのフォルダに入っているか | | 設定後も動かない | **Claude Code を一度終了して再起動する** | 実際に起きたのは1つ目でした。**シートをサービスアカウントと共有し忘れたまま指示を出し、「権限がありません」を連発させています。**鍵を渡していない状態で開けようとしていたわけです。 ### ファイルの置き場所は最初に決める もう1つ、地味ですが重要な教訓があります。**Claude Code に任せるファイルは、置き場所（フォルダ）を最初に決めておくことです。** 後からファイルを別の場所に移すと、AIが元の場所を探しに行きます。**実際に、ファイルを移動して過去の作業履歴が失われる事故が発生しました。**最初に定位置を決めておくだけで、この種のトラブルはかなり防げます。 ## 実際に自動化された作業 - **Gmailの受信を監視してシートのステータスを自動更新**：特定のメールが来たら管理表の状態を自動で書き換える。手作業の転記がゼロに - **月次KPIの自動集計**：複数のシートに散らばった数字を、毎月まとめて1枚に集計 - **アンケート回答をDiscordに自動通知**：回答が入るたびにチームのDiscordへ通知 いずれも派手さはなく、**毎月・毎回、手でやっていた地味な作業**です。人がやらなくてよいものをAIに寄せた結果として時間が生まれています。 ## スプレッドシート以外にも広がる この接続の仕組みはスプレッドシート専用ではありません。**同じGoogleの許可設定を土台に、他のサービスも Claude Code とつながります。** | サービス | できること | | --- | --- | | ドキュメント | 議事録や報告書の自動作成 | | YouTube | 動画の字幕を取得して記事化 | | Gmail | メールの自動分類・監視・下書き作成 | | Google Drive / フォーム | ファイル整理・回答の自動集計 | **一度つなぎ方を覚えると、自動化できる範囲が一気に広がります。** ## よくある質問 ### サービスアカウントとは何ですか？ **人間ではなく、プログラム専用のGoogleアカウントです。**普段シートを誰かと共有するのと同じ手順でこのアカウントに共有すると、Claude Code が読み書きできるようになります。 ### 設定にどれくらいかかりますか？ **15〜20分程度です。**しかも初回だけで、以降は使いたいシートを共有する（STEP 5）だけで使い回せます。 ### 「権限がありません」と出ます **シートの共有設定で、サービスアカウントのメールアドレスが正しく入っているか確認してください。**共有を忘れたまま指示を出すのが最も多いつまずき方です。 ### 設定したのに動きません **Claude Code を一度終了して再起動してください。**設定ファイルへの追記後は再起動が必要です。それでも動かない場合は、JSONファイルの置き場所を確認します。 ### プログラムを書く必要はありますか？ **ありません。**やっているのはサービスアカウントにシートを共有することだけで、実質的に「AIに鍵を1本渡す」作業です。指示も日本語で出します。 ## まとめ - コピペの往復は**サービスアカウントにシートを共有するだけ**で消える - サービスアカウントは**プログラム専用のGoogleアカウント**。共有の考え方は普段と同じ - 設定は**15〜20分・初回のみ**。シートを増やすときは共有（STEP 5）だけ - ロールと共有権限は**どちらも「編集者」** - **JSONキーは鍵そのもの**なので取り扱いに注意する - 最多のつまずきは**共有し忘れによる「権限がありません」** - **ファイルの置き場所は最初に決める。**後から移すと作業履歴を失う事故が起きる - 同じ土台で**ドキュメント・YouTube・Gmail・Drive・フォーム**へ展開できる 自動化の効果は、派手な機能よりも「毎回手でやっていた受け渡し」を消したときに出ます。接続の仕組みを一度作れば、対象を広げるコストはほぼゼロになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のバックオフィス業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## ローカルで完璧でも本番で落ちる｜WordPressプラグイン公開が2回続けて止まった原因 - URL: https://ai-katsu.jp/articles/wp-plugin-release-failure - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-28T00:00:00+00:00 - Models: Claude Code, Gemini, OpenAI Codex - Tools: Google Apps Script - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: 教育・研修 > 2ヶ月かけて開発した証明書自動発行プラグインが、本番リリースで2回連続して停止しました。1回目はZIPにincludes/フォルダが欠落してサイト全体がダウン、2回目はWindowsとLinuxのパス区切り文字の差異。AIが担えない配布・インフラ領域の実例をそのまま記録しています。 「ローカルで完璧に動いた」は「本番でも動く」を意味しません。**AIがコードを書けるようになっても、この壁は残ります。** この検証では、**2ヶ月かけて開発したWordPressプラグインが、本番リリースで2回連続して止まりました。**原因はいずれもコードではなく、ZIPの作り方という配布側の問題です。失敗した経緯と具体的なエラー内容をそのまま記録します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年6月 | | 作ったもの | 受講証明書の自動発行システム（WordPressカスタムプラグイン） | | 開発期間 | **約2ヶ月** | | 規模 | **6コース・全246課題** | | ローカル検証 | **全246課題を実際に提出してE2Eテスト完了** | | 結果 | **本番導入で2回連続失敗。1回目はサイト全体がダウン** | | 現在 | 本番未反映のまま作業を一時停止中 | > 本記事は、グループ会社である**株式会社バイテックでの検証記録**をもとに、当社の検証レポート形式で再構成したものです。数値・エラーメッセージ・原因の切り分けは、検証時の記録をそのまま記載しています。原文は[note の公開記事](https://note.com/makun_bytech/n/nd04caa98abed)（2026年6月28日公開）をご覧ください。 ## 結論：AIが担う範囲の外側で止まった | 領域 | 今回の状況 | | --- | --- | | コードの実装・ロジック設計 | **問題なし。**AIが書き、ローカルで全テスト通過 | | 採点精度の検証 | 問題なし。実際の提出物で確認済み | | **ZIPの構造・パス区切り文字** | **ここで2回止まった** | **AIはコードを書き、ロジックを考え、採点まで担いました。しかし「ZIPの構造が正しいか」「サーバーのパス区切り文字は何か」という配布・インフラ側の知識は、AIに頼り切れない領域として残りました。** ## 作ろうとしたシステム もともとのフローは全て手作業でした。 ``` 受講生がLINEで成果物を送る → 講師が添削してフィードバック → 合格を運営に報告 → 運営がFigmaで証明書を作成 → スプレッドシートに記録 → 受講生に連絡 1件に複数人が関わり、数日かかる ``` これを次のように全自動化する設計にしました。 ``` 受講生がレッスンページ内のフォームで課題を提出 → Gemini が自動採点し、合否＋フィードバックを即表示 → 不合格なら再提出、合格で次の課題が解放 → レベル内の全8課題に合格 → 担当講師を選択して証明書を発行 → 証明書PNG 2枚を自動生成（公式デザイン） → Google Drive に保存＋管理シートに自動記録 → シェア用の投稿文も自動表示 ``` | 項目 | 内容 | | --- | --- | | 対象コース | AIライティング／ChatGPT／Gemini／Dify／NotebookLM／Microsoft Copilot の**6コース** | | 課題数 | **246課題** | | 採点コスト | **Gemini の無料枠を使用するためゼロ** | | 実装形態 | WordPress のカスタムプラグインとして自作 | WordPress のプログラムを書いた経験はほぼない状態から、Claude Code に相談しながら構築しています。 ## ローカルでは全て通っていた 約2ヶ月かけて、ローカル環境での動作確認は徹底しました。 - **全246課題を実際に提出して採点させた** - 初級 → 中級 → 上級の**連鎖ロック解除**を確認 - 実際の受講生の提出物を使って**採点精度を検証** - 証明書を実際に発行してデザインを確認 テキストだけで判定する課題と、**スクリーンショット画像をAIが見て採点する課題**の両方を実装しています。E2Eテストが全て完了した時点で「あとは本番に入れるだけ」という状態でした。 ## 1回目の失敗：サイト全体がダウンした WordPressプラグインの導入は、ZIPファイルを管理画面からアップロードするだけです。ローカルのフォルダをZIPに圧縮し、「プラグインを新規追加」→「ZIPでアップロード」を実行しました。 **アップロードした瞬間、学習サイト全体がダウンしました。** ``` class-bsc-activator.php というファイルが見つからない ``` 該当ファイルはローカルに存在します。原因は**ZIPの中に includes/ フォルダが丸ごと欠落していたこと**でした。 | プラグインが探すパス | ZIP展開後の実際のパス | | --- | --- | | `includes/class-bsc-activator.php` | `class-bsc-activator.php` | **Windows でフォルダを右クリック → 「圧縮」でZIPを作ると、フォルダ構造が意図どおりに入らないことがあります。**今回は includes/ の中身だけが入り、フォルダ自体がZIPに含まれていませんでした。 プラグインを即削除してサイトは復旧し、**ダウンから数分で戻りました**。深夜に発生していた場合を考えると軽微では済まない事象です。 ## 再挑戦の前にセキュリティレビューを実施 ZIPの問題を直す前に、ChatGPT Plus（OpenAI Codex機能）にソースコードをアップロードしてセキュリティレビューを依頼しました。**5件の問題が見つかっています**（記録に残っている内訳は次の4点）。 - **画像アップロードで悪意あるファイルを受け付けてしまう可能性** - **証明書が二重発行される可能性** - テスト用のコードが本番に残ったまま - APIのシークレットキーが古いまま 全て修正し、**シークレットキーも新しいものに変更してGASを再デプロイ**しました。ZIPの作り方も、Windows の右クリック圧縮ではなく**コマンドラインで正しい構造になるよう作り直しています。** ## 2回目の失敗：有効化で「存在しません」 構造を確認したうえでアップロードしたところ、**インストール自体は成功**しました。 ``` プラグインのインストールが完了しました 　↓ 「プラグインを有効化」を押す プラグインファイルが存在しません ``` インストールはできているのに、起動しようとするとメインファイルが見つからないと言われる状態です。 原因の推測は次のとおりです。**Windows で作ったZIPのファイルパスは、区切り文字に「\\（バックスラッシュ）」を使うことがあります。一方 Linux のサーバーは「/（スラッシュ）」しか受け付けません。**ZIP展開時にパスが正しく解釈されず、ファイルの場所がずれた可能性があります。 **不要な外部ライブラリを除外してパスを修正した12MBのZIP**を準備した時点で、作業を一時停止しました。**2ヶ月分の開発は、本番に乗らないまま止まっています。** ## この失敗から言えること ### ローカルで動くことと本番で動くことは別 **ローカル環境は自分のPCの中だけで完結します。本番サーバーはOS・PHPのバージョン・ファイル権限など、あらゆる条件が異なります。**「ローカルで完璧に動いた」は「本番でも動く」を意味しません。 ### AIが得意な領域とインフラは別 AIはコードを書き、ロジックを考え、採点まで担えます。**しかしZIPの構造やサーバーのパス区切り文字といった地味なインフラの知識は、AIに頼り切れない部分として残ります。** 「AIで全自動化できた」という話の裏には、こうした作業が必ず存在します。 ## よくある質問 ### なぜ1回目でサイトがダウンしたのですか？ **ZIPの中に includes/ フォルダが丸ごと欠落していたためです。**プラグイン本体が `includes/class-bsc-activator.php` を参照するのに、展開後は `class-bsc-activator.php` になっており、ファイルが見つからずサイト全体が停止しました。 ### ZIPはどう作るべきでしたか？ **Windows の右クリック圧縮ではなく、コマンドラインで構造を確認しながら作成します。**右クリック圧縮ではフォルダ構造が意図どおりに入らないことがあります。 ### 2回目の「プラグインファイルが存在しません」の原因は？ **Windows のパス区切り文字「\\」と、Linux サーバーが受け付ける「/」の差異が原因と推測しています。**ZIP展開時にパスが正しく解釈されず、ファイルの場所がずれた可能性があります。この時点で作業を一時停止しました。 ### AIに任せられなかったのはどこですか？ **ZIPの構造とサーバーのパス区切り文字という、配布・インフラ側の知識です。**コードの実装・ロジック設計・採点精度の検証は問題なく通っていました。 ### 採点にコストはかかりましたか？ **かかっていません。**Gemini の無料枠を使用する設計のため、246課題の採点コストはゼロです。 ## まとめ - **2ヶ月・6コース・246課題を実装し、ローカルでは全テストを通過**していた - それでも**本番導入で2回連続して停止。1回目はサイト全体がダウン**した - 1回目の原因は**ZIPに includes/ フォルダが含まれていなかったこと**（Windows の右クリック圧縮） - 2回目の原因は**Windows の「\\」と Linux の「/」というパス区切り文字の差異**と推測 - 再挑戦前のセキュリティレビューで**5件の問題を検出**。二重発行やテストコードの残存など - **ローカルで動く ≠ 本番で動く。**OS・PHPバージョン・ファイル権限が異なる - **AIはコードを書けるが、ZIP構造やパス区切り文字といったインフラ側は残る** 自動化の難所は、しばしばロジックではなく配布と環境差にあります。AIが実装を担うほど、この領域が相対的に大きな比重を占めるようになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## X公式APIで課金に詰まった｜Buffer経由に逃がして投稿コストをゼロにした設計 - URL: https://ai-katsu.jp/articles/x-posting-buffer-automation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-17T00:00:00+00:00 - Models: Claude Code - Tools: X（旧Twitter）, Discord - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: マーケティング > X公式APIは投稿1本ごとの従量課金で、残高ゼロでは1本も投稿できません。無料SNS予約ツールBuffer経由に切り替えて投稿コストをゼロにしました。スプレッドシート1枚を司令塔にし、ネタ切れ時はDiscordへ補充通知が飛ぶ構成まで、未経験者がコードを書かずに構築した記録です。 SNS運用の自動化は、コードが書けるかどうかより**「どこで課金されるか」を先に把握できているか**で成否が分かれます。動くものはすぐできても、課金設計を外すとその時点で止まります。 この検証では、**X（旧Twitter）公式APIで課金に詰まったあと、無料SNS予約ツール Buffer 経由に切り替えて投稿コストをゼロにしました。**プログラミング未経験の担当者が、コードを1行も書かずに構築しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年6月 | | やりたかったこと | 企業のXアカウント運用を、担当者の頑張りに依存しない仕組みにする | | 最初の失敗 | **X公式APIは投稿1本ごとの従量課金。**残高がないと1本も投稿できない | | 解決策 | **Buffer の無料プランで使えるAPI経由に切り替え、投稿コストをゼロに** | | 人の作業 | スプレッドシートに行を足すことだけ | | 実装者 | プログラミング未経験。コードはすべて Claude Code が記述 | > 本記事は、グループ会社である**株式会社バイテックでの検証記録**をもとに、当社の検証レポート形式で再構成したものです。数値・設定値・エラー内容は、検証時の記録をそのまま記載しています。原文は[note の公開記事](https://note.com/makun_bytech/n/ncb10a0ffe440)（2026年6月17日公開）をご覧ください。 ## 結論：詰まったのは実装ではなく課金ポイントだった Claude Code に「こうしたい」と伝えると、X公式APIを使う実装はすぐに完成しました。**動かない原因はコードではなく、料金体系のほうにありました。** ``` 【最初の設計】 スプレッドシート → プログラム → X公式API → 投稿 ↑ 投稿1本ごとに課金 残高ゼロで全て弾かれる 【切り替え後】 スプレッドシート → プログラム → Buffer（無料プラン） → 予約投稿 → X ↑ 投稿コストなし 公式に認められた経路 ``` 発想を「自動投稿を作る」から**「課金される部分を無料の経路に逃がす」**に変えたことで、設計が一気に通りました。 ## 最初の失敗：残高ゼロで1本も投稿できない 実装自体は短時間で完成したものの、実行すると投稿が弾かれました。返ってきたエラーは**「クレジットがゼロなので実行できません」**という内容です。 調べたところ、**X公式APIは投稿1本ごとに料金が発生する従量課金で、残高がないと1本も投稿できない仕様**でした。 ツールは動く、しかしコスト設計を誤るとそこで止まる。**これはAI活用で頻出する止まり方です。** ## 立て直し：Buffer 経由に切り替える 調査の結果、無料のSNS予約ツール **Buffer** に、無料プランでも使えるAPIがあることが分かりました。X公式APIを直接叩くのをやめ、Buffer 経由で投稿する形に変更しています。 - **投稿コストがゼロになった** - **アカウント凍結の心配がない**（公式に認められた経路のため） 「高いから無理」ではなく、**どこに課金が発生するかを把握して設計で避ける**。この切り替えが転換点でした。 ## 構成：スプレッドシート1枚が司令塔 | 担当 | やること | | --- | --- | | **人** | **スプレッドシートにネタを溜める（作業はこれだけ）** | | プログラム | 定期的にシートを読み取り、Buffer へ送る | | Buffer | 決めた時刻に自動でXへ投稿する | **スプレッドシート1枚が運用全体の司令塔**になり、人の作業は行を足すことだけになりました。 ## ネタ切れも仕組みで防ぐ 自動投稿で実際に問題になるのは、仕組みそのものより**ネタ切れ**です。ここも自動化の対象にしました。 - 日々集まる成果事例を投稿ネタの素材にする（**個人が特定されないよう匿名化**したうえで使用） - **文章への整形・文字数チェック・ハッシュタグ付けまでを自動化** - **ストックが減ったら Discord のチャットに「補充して」と通知が飛ぶ** 常時気にかける必要がなく、**減ったときだけ動けばよい状態**になったことで、運用の手離れが実現しました。 ## 未経験でも組めた理由 コードはすべて Claude Code が書いています。担当者がやったのは**「何を、どうしたいか」を言葉にすること**だけでした。 ``` 「スプレッドシートのこの列を読んで、この時間に投稿して」 「課金されるから、無料の経路に変えて」 ``` 凝ったプロンプトは使っていません。**必要なのはコードの知識ではなく、自分の業務を分解して言葉にする力**だったという結論です。分からないことはそのままAIに聞けば返ってきます。 ## 同じ形で始めるための4ステップ | ステップ | 内容 | | --- | --- | | **1\. 小さく始める** | いきなり全部やらない。「1日1投稿だけ自動化」から | | **2\. 課金ポイントを先に洗い出す** | **「どこでお金がかかるか」を最初に確認する。**動かしてから詰むのを防げる | | **3\. 無料の逃がし先を探す** | 有料機能に無料の代替がないか調べる。Buffer のように見つかることがある | | **4\. 人の確認を1か所だけ残す** | **全自動にしすぎない。**最後のチェックは人が見る | ## よくある質問 ### X公式APIは使えないのですか？ **使えますが、投稿1本ごとの従量課金です。**残高がないと1本も投稿できません。無料で運用したい場合は、Buffer のように無料プランでAPIが使えるツールを経由する設計になります。 ### Buffer 経由はアカウント凍結のリスクがありませんか？ **公式に認められた投稿経路のため、その心配はありません。**非公式な自動化とは異なります。 ### プログラミングの知識は必要ですか？ **今回は不要でした。**コードはすべて Claude Code が書いています。必要だったのは「何を、どうしたいか」を具体的な言葉にすることでした。 ### 自動投稿でネタが尽きませんか？ **ネタ切れこそ最大の課題なので、そこも仕組みにしました。**素材から投稿文への整形・文字数チェック・ハッシュタグ付けを自動化し、ストックが減ったら Discord に補充依頼が飛ぶようにしています。 ### 全自動にしないのはなぜですか？ **品質と安心を担保するためです。**人の確認を1か所だけ残す設計にしています。全自動にしすぎないことが、結果的に運用を続けやすくします。 ## まとめ - 止まった原因は実装ではなく**課金ポイントの見落とし**だった - **X公式APIは投稿1本ごとの従量課金。**残高ゼロでは1本も出せない - **Buffer の無料プランAPI経由に切り替えて投稿コストをゼロに。**公式経路なので凍結リスクもない - 構成は**スプレッドシート1枚が司令塔**。人の作業は行を足すことだけ - **ネタ切れ対策まで仕組みに含める。**ストックが減ったら Discord に通知 - 未経験でも組めた理由は**業務を分解して言葉にできたこと**。コードはAIが書く - 始め方は**小さく始める → 課金ポイントを先に洗う → 無料の逃がし先を探す → 人の確認を1か所残す** AIツールのコストは「高い・安い」ではなく、どこに発生するかを把握できているかで決まります。設計前に課金点を洗い出しておけば、動かしてから詰まる事態は避けられます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 動いたが公開しなかった｜チラシ収集エージェントで学んだ技術と法の線引き - URL: https://ai-katsu.jp/articles/chirashi-automation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-09T00:00:00+00:00 - Models: OpenAI API - Tools: Browser Use, Discord - Tasks: リサーチ・データ収集, 業務プロジェクト - Domain: マーケティング > 郵便番号から近隣スーパーのチラシを収集・Vision解析する仕組みを構築し、75ステップ完走で30枚の取得に成功しました。しかし著作権と利用規約を考慮し、一般公開はしない判断に。テキスト層とVision層の役割分担、トークン消費を5〜10分の1にした設計もまとめています。 近隣スーパーの特売チラシを毎朝確認するのは手間ですが、それ以上に**横断比較ができないため、どこが一番安いか判断しにくい**という問題があります。 この検証では、郵便番号を入力するだけで近隣スーパーのチラシを収集・解析する仕組みを作りました。**技術的には動きましたが、公開はしないという判断をしています。** ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年6月8日〜（検証中） | | やりたかったこと | 郵便番号を入力するだけで「今日の近隣スーパー特売一覧」が自動生成される仕組みを構築する | | 構成 | Browser Use CLI（画像取得）＋ Vision解析（チラシ読み取り）＋ 常駐型エージェント（オーケストレーション） | | 成果 | **75ステップ完走、チラシ画像30枚を取得・解析** | | ランニングコスト | **約¥30/月**（軽量モデルでオーケストレーション＋Vision） | | 判断 | **個人利用に限定。一般公開はしない** | ## 結論：技術的にできることと、公開してよいことは別 この検証で最も重要な判断です。 当初は3ステップの構想がありました。 1. 個人用CLI 2. ブラウザからアクセス可能に 3. 広告付きで一般公開 しかし**調査の結果、チラシデータの法的リスクが判明し、ステップ1（個人利用）に限定する判断をしました。** 理由は明確です。**チラシ画像の著作権と、情報ポータルの利用規約を考慮し、再配信しない**という判断です。 **「自分で見るために自動化する」ことと、「集めたものを他人に配信する」ことは、法的にまったく違います。**この線引きを検証の途中で確認したことに意味があります。 ## 設計の要点：テキスト層と画像層を分ける 技術的に最も効いた設計判断です。 | 層 | 対象 | 手法 | | --- | --- | --- | | **テキスト層** | 店舗一覧 | **DOM から抽出** | | **画像層** | チラシの中身 | **Vision解析** | **この役割分担が明確で、実装がシンプルになりました。** チラシは画像なので、中身を読むにはVisionが必要です。しかし「どの店舗があるか」はHTMLに書かれています。**全部をVisionで解こうとすると、コストも精度も悪化します。** ## ブラウザ操作を「ツール」として呼ぶ トークン効率に大きく影響した判断です。 **Playwrightでコードを生成させる方式ではなく、ブラウザ自動化CLIをツールとして呼び出す方式を採用しました。** 効果は明確です。**LLMのトークン消費を5〜10分の1に削減**できました。 AIにコードを書かせると、コード自体が出力トークンになります。**既にあるコマンドを呼ぶだけなら、その分が不要になります。** ## 実装で詰まった点 | 問題 | 原因 | 対処 | | --- | --- | --- | | 想定していたURLが404 | サイト構造が想定と違った | 店舗ページ本体の画像CDN URLを直接ダウンロードする方式へ変更 | | **シェル展開が効かない** | Python subprocess経由ではシェルの展開が行われない | ファイルを読み込んで実行する専用ツールを別途実装 | | **Vision APIが空レスポンスを返す** | **推論トークンが不足していた** | 出力トークン上限を2000 → 8000へ引き上げ | | 環境変数が空になる | モジュールレベルで読むと、読み込み処理より先に評価される | 参照タイミングを遅らせる | 3つ目が特徴的です。**推論モデルでは、出力トークンの上限に「思考」の分も含まれます。**通常の感覚で上限を設定すると、答えを出す前に打ち切られて空になります。 また、**推論モデルでは従来の `max_tokens` ではなく `max_completion_tokens` を使う**という仕様差も記録されています。 ## 高解像度版を取得する 実装上の発見です。 **画像CDNのURLに含まれるサイズ指定パラメータを置き換えることで、高解像度版を取得できました。** Vision解析では、画像の解像度が読み取り精度に直結します。**表示用のサムネイルではなく、元の解像度で取得できるかどうかが結果を左右します。** また、一部の店舗については**公式サイトから直接取得できるURLパターンを発見し、ブラウザ自動化なしで取得**できるようになりました。 **ポータル経由でなくても取れるものは、直接取ったほうが速くて確実です。** ## 絞り込みの精度をどう出すか この仕組みで意外と難しいのが、対象店舗の選別です。 検索結果には業種を問わず大量の店舗が含まれます。そこから食品スーパーだけを抽出する必要があります。 対処として**多層のスーパー判定**を実装しました。 - **ホワイトリスト**（30以上のチェーン） - **ブラックリスト** - **店名の正規化** 結果、**業種無差別の327件から食品スーパー26件を正確に絞り込み、誤判定をほぼゼロ**にできました。 さらに**「常時取得店舗」を固定登録する仕組み**も併用しています。**自動判定に頼りきらず、確実に取りたい対象は明示的に登録しておく**という設計です。柔軟性と確実性を両立できます。 ## 通知：優先順位で経路を切り替える 結果の届け先も実装しています。 ``` Discord Webhook → 別の通知サービス → ターミナル出力 ``` 環境変数が設定されていれば上位の経路を使い、なければ下位にフォールバックする構成です。 実装は**標準ライブラリのみで、追加依存なし**。文字数制限を超える場合は末尾を自動トリムする処理も入れています。 **通知先の制約（文字数上限）に合わせる処理を入れておかないと、長い結果で失敗します。** ## コスト **月間ランニングコストは約¥30**という試算です。オーケストレーションとVisionの両方を軽量な推論モデル1つで担当しています。 **Vision と Function Calling を1モデルで担えるため、アーキテクチャがシンプルになりました。**モデルを使い分けると、その分だけ構成が複雑になります。 ## 既存資産の再利用 この検証がスムーズに進んだ理由も記録されています。 **既存スキルの巡回ループ・待機の作法・出力プレフィックスの処理をそのまま流用できました。** ブラウザ自動化で必要になる処理は、対象が変わっても共通する部分が多くあります。**一度作った作法を型として持っておくと、2つ目以降が速くなります。** ## 残っている改善点 - チラシ有無の事前判定（未登録店の早期スキップ）による効率化 - 他店舗の公式サイトからの直接取得への対応 - **複数日にわたるチラシ履歴の蓄積と「いつもより安い」検出機能** 3つ目が本質的です。**今日の価格だけでは「安いかどうか」は判断できません。**履歴があって初めて比較になります。 ## よくある質問 ### なぜ一般公開しないのですか？ **チラシ画像の著作権と、情報ポータルの利用規約を考慮したためです。**自分で見るために自動化することと、収集したものを他人に配信することは法的に別の問題になります。 ### トークン消費を抑えるコツは？ **AIにコードを書かせず、既存のCLIをツールとして呼ぶことです。**この検証では消費を5〜10分の1に削減できました。 ### Vision APIが空を返します **推論モデルでは出力トークンの上限に思考分も含まれます。**上限が低いと答えを出す前に打ち切られます。この検証では2000から8000へ引き上げて解消しました。 ### 画像の解析精度を上げるには？ **高解像度版を取得することです。**画像CDNのサイズ指定パラメータを置き換えることで、表示用サムネイルではなく元解像度の画像を取得できる場合があります。 ## まとめ - **技術的にできることと、公開してよいことは別。**調査の結果、個人利用に限定する判断をした - 設計の要点は**「テキスト層はDOM抽出、画像層はVision解析」の役割分担** - **AIにコードを書かせず既存CLIをツールとして呼ぶ**ことで、トークン消費を5〜10分の1に削減 - 推論モデルでは**出力トークン上限に思考分が含まれる。**低いと空レスポンスになる - Vision解析では**高解像度版の取得**が精度に直結する - 絞り込みは**自動判定＋固定登録の併用**で柔軟性と確実性を両立 - 既存スキルの作法を流用すると**2つ目以降が速くなる** 自動化を進めるときは、技術的な可否と同時に、その使い方が許されるかを確認する必要があります。動いたものを公開しない判断も、検証の成果の1つです。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 同一LPを2基盤で実測比較｜総合スコアだけ見ると逆の結論になる - URL: https://ai-katsu.jp/articles/vercel-cloudflare-lp-performance - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-08T00:00:00+00:00 - Tools: Vercel, Cloudflare, Browser Use - Tasks: 開発・エンジニアリング, ツール検証 - Domain: マーケティング > 同じLPをVercelとCloudflare Pagesで公開し、PageSpeed Insightsで実測しました。FCP・Speed Index・TBTは全条件でCloudflareが速い一方、モバイル総合スコアだけ逆転。原因はLCPの単発値で、内訳を見ないと判断を誤ります。速度差の源泉とよくある誤解の訂正もまとめています。 「こっちのほうが速い気がする」——体感は当てにならないことも多いですが、確かめる価値はあります。 この検証では、**同一のLPを2つのホスティング基盤で公開し、実測で比較**しました。結果、体感は数値で裏づけられましたが、**総合スコアだけを見ると逆の結論になる**という落とし穴もありました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年6月8日 | | 対象 | Vercel / Cloudflare Pages（同一LPを2環境で公開） | | 計測 | PageSpeed Insights（Lighthouse 13.3.0）でモバイル・デスクトップ両方 | | 結果 | **FCP・Speed Index・TBTは全条件でCloudflareが速い** | | 状況 | 完了 | ## 結論：初回描画はCloudflareが一貫して速い ### モバイル（低速4G相当） | 指標 | Vercel | Cloudflare | 速い方 | | --- | --- | --- | --- | | **パフォーマンス総合** | **99** | 75 | **Vercel** | | FCP | 1.1秒 | **0.9秒** | Cloudflare | | **Speed Index** | 2.7秒 | **1.1秒** | **Cloudflare** | | TBT | 70ms | **40ms** | Cloudflare | | **LCP** | **1.7秒** | 9.9秒 | **Vercel** | ### デスクトップ | 指標 | Vercel | Cloudflare | 速い方 | | --- | --- | --- | --- | | パフォーマンス総合 | 85 | **93** | Cloudflare | | FCP | 0.5秒 | **0.2秒** | Cloudflare | | **Speed Index** | 1.1秒 | **0.5秒** | **Cloudflare** | | **TBT** | 130ms | **0ms** | **Cloudflare** | | LCP | 2.4秒 | **1.8秒** | Cloudflare | なお、**ユーザー補助（93）・おすすめの方法（100）・SEO（100）は全条件で両環境同値**でした。差はパフォーマンス領域に限定されます。 ## 総合スコアだけを見てはいけない この検証で最も重要な指摘です。 **モバイルの総合スコアだけ Vercel 99 / Cloudflare 75 と逆転しています。**しかし内訳を見ると、FCP・Speed Index・TBTはすべてCloudflareが速い。 逆転の要因は1つです。**Cloudflare側モバイルLCPの単発値 9.9秒**。 ここで冷静に見るべき点があります。**同一画像でデスクトップは1.8秒、Vercelのモバイルでも1.7秒**です。9.9秒という値だけが突出しています。 **初回アクセス時のキャッシュ未ウォームや計測変動の影響が大きいと考えられ、プラットフォームの実力差ではない可能性が高い**という判断になります。 **1つの数値が総合スコアを大きく動かすことがあります。**スコアだけで判断すると、内訳と逆の結論に至ります。 ## なぜCloudflareのほうが初回描画が速いのか 理由はネットワーク構成にあります。 | 観点 | Cloudflare | Vercel | | --- | --- | --- | | **エッジ拠点（PoP）** | **337都市・100カ国以上** | 126 PoP / コンピュート20リージョン | | 配信方式 | **全拠点同一IPのAnycast**（自動で最寄り誘導） | PoP → 最寄りリージョンへルーティング | | エッジ実行 | V8 isolates（**コールドスタート5ms未満**） | サーバーレス基盤 / Edge Runtime | **PoP数が約2.5〜3倍あり、Anycastでユーザーへの物理距離（RTT）が短くなります。**そのためTTFB・初回描画が小さくなります。 重要なのは、**この差は日本・東南アジアなど、北米/西欧の外側ほど開きやすい**という点です。 **海外のベンチマーク記事の結果が、日本からのアクセスでそのまま当てはまるとは限りません。** ## 用途で分ける 2026年時点での住み分けは明確です。 | 用途 | 推奨 | 理由 | | --- | --- | --- | | **静的サイト・LP配信** | **Cloudflare** | PoP数とAnycastで初回描画が速い | | **重い動的処理・SSR** | **Vercel** | 計算量の多い処理で有利 | **「静的＝Cloudflare／動的SSR＝Vercel」**という整理です。 なお、動的処理の性能差については提供元の自社ベンチマークの数値がありますが、**中立性には留保が必要**という但し書きも記録されています。 ## よくある誤解の訂正 この検証では、事実確認の記録も残されています。 **「CloudflareとGoogleの資本提携」は誤解されやすい**——という点です。 2015年にGoogle系の投資部門が出資したのは事実ですが、**Cloudflareは2019年にNYSE上場した独立企業**です。現在Google傘下でも資本提携でもありません。現存するのはGoogle Cloudとの技術提携程度です。 **速度の源泉はGoogleに由来しません。**自前の337都市Anycastネットワークと独自ランタイムによるものです。 **技術選定の理由を顧客に説明するとき、誤った前提を伝えないための確認**として重要な記録です。 ## 計測方法のTips 実務的な工夫も記録されています。 **PageSpeedの解析ページはスコアをJavaScriptで動的描画するため、通常のHTTP取得では取れません。** 対処として、ブラウザ自動化ツールで `open` → `eval "document.body.innerText"` によりスコアを抽出しました。 **JSで描画されるページからデータを取る場合、ブラウザを動かす必要があります。** ## 計測上の留意点 - **ラボデータは単一実行の推定値で、実行ごとに変動する** - 単一実行値での結論は避け、**複数回計測が望ましい** - この検証では両環境とも画像が非WebP等で、**約1,618 KiBの削減余地**があった 最後の項目は重要です。**ホスティングを比較する前に、コンテンツ側の改善余地が残っていました。**基盤を変えるより、画像を最適化するほうが効果が大きいケースもあります。 ## よくある質問 ### どちらが速いですか？ **初回描画（FCP・Speed Index・TBT）は全条件でCloudflareが速いという結果でした。**ただしモバイルの総合スコアだけは逆転しており、これはLCPの単発値が支配的な要因です。 ### 総合スコアで判断してよいですか？ **内訳の確認が必要です。**この検証では、1つの指標の単発値が総合スコアを大きく動かし、内訳と逆の結論になりました。 ### 海外のベンチマーク結果は参考になりますか？ **そのまま当てはまらない場合があります。**PoP数の差による効果は、北米・西欧の外側ほど大きくなります。日本からのアクセスで測る価値があります。 ### Cloudflareが速いのはGoogleとの関係ですか？ **違います。**Cloudflareは2019年に上場した独立企業で、Google傘下でも資本提携でもありません。速度は自前の337都市Anycastネットワークと独自ランタイムによるものです。 ## まとめ - **初回描画（FCP・Speed Index・TBT）は全条件でCloudflareが速い** - **モバイル総合スコアだけ逆転**。ただし要因はLCPの単発値で、実力差ではない可能性が高い - **総合スコアだけを見ると内訳と逆の結論になる。**必ず内訳を確認する - 速度差の源泉は**PoP数（約2.5〜3倍）とAnycast構成**。北米・西欧の外側ほど差が開く - 2026年時点の住み分けは**「静的＝Cloudflare／動的SSR＝Vercel」** - ラボデータは変動するため**複数回計測が望ましい** - **基盤を変える前に、画像最適化などコンテンツ側の改善余地を確認する** 技術選定の根拠は、体感でも一般論でもなく実測で持つと説明しやすくなります。ただしスコアの見方を誤ると、数値があっても判断を間違えます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のWeb制作・インフラ選定を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 常駐型AIエージェント基盤という選択肢｜コーディングエージェントとはレイヤーが違う - URL: https://ai-katsu.jp/articles/hermes-agent - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-05T00:00:00+00:00 - Models: Claude Code - Tools: MCP, Browser Use - Tasks: AIエージェント, ツール検証 > サーバーに常駐し、20以上のチャットチャネルから指示を受け、定期実行もこなすOSSエージェント基盤を調査しました。価値は「運用の配管」が標準で揃っていること。監視・収集・定例配信のような高頻度タスクほど、ローカルモデル併用でコスト差が出ます。使い分けの判断軸をまとめています。 AIエージェントというと、IDEの中でコードを書く補助ツールを思い浮かべます。しかし別の系統があります。**自分のサーバーに常駐し、複数のチャットチャネルから指示を受け、定期実行もこなす**タイプです。 この調査では、そうしたOSSエージェント基盤を公開ドキュメントから精読し、**既存のコーディングエージェントとの位置づけの違い**を整理しました。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査日 | 2026年6月5日 | | 対象 | Hermes Agent（Nous Research）v0.15.2／**MITライセンス** | | 方法 | **公開ドキュメント全文（約61,000行）を取得・精読する机上調査**（実インストールは未実施） | | 本体費用 | **0円**（OSS）。かかるのは接続したLLMのAPI課金のみ | | 判定 | **条件付きで導入可**（★4.0/5・机上調査時点） | > 本記事は公開ドキュメントに基づく調査記録です。実機での精度・安定性・運用負荷は未実測のため、公称値ベースの記載を含みます。 ## 結論：レイヤーが違う この調査で最も重要な整理です。 **Hermesは「コーディングエージェント」ではなく「サーバー常駐の汎用業務エージェント基盤」です。** 設計思想で割り切ると、こう整理できます。 | ツール | 正体 | | --- | --- | | **Hermes** | **運用フレームワーク**（常駐型・汎用業務エージェント基盤） | | **Claude Code / Codex** | **コーディングエージェント本体** | | エッジ系のAgents SDK | エージェントを「作る」土台（サーバーレス前提） | **同じ「AIエージェント」でも、比較すべき軸が違います。**コーディング品質で比べても意味がありません。 ## 4つのインターフェースが状態を共有する この設計が特徴的です。 **同一のエージェントコア・同一の設定/セッション/スキル/メモリを、複数のフロントエンドから操作します。** 1. **CLI / TUI** — ターミナルUI本体 2. **Web Dashboard** — 設定/セッション/ログ/cronをGUI管理（**完全ローカル実行**） 3. **Desktop App** — チャット中心のネイティブGUI 4. **Messaging Gateway** — **20以上のチャネルに単一プロセスで接続** **CLIで開始してDesktopで再開する、といった相互レジュームが可能です。**作業の続きを別の場所から拾えます。 ## 「運用の配管」が標準で揃っている この基盤の本質的な価値はここにあります。 | 機能 | Hermes | コーディングエージェント | | --- | --- | --- | | **常駐のしやすさ** | **◎ コマンド一つでOS常駐** | △ 自前で常駐ループ実装 | | **スケジューリング（cron）** | **◎ 標準装備（自然言語cron）** | ✕ 自作 | | **メッセージング連携** | **◎ 20以上のチャネル標準** | ✕ 自作 | | 永続メモリ/スキル | ◎ 標準装備 | ◎ あり | | **セルフホスト** | **◎** | × | | **コーディング品質/IDE統合** | ○（汎用） | **◎** | **「配管をほぼ書かなくていい」**——これが差になります。定期実行、チャネル接続、通知配信、記憶の保持を自前で実装すると、それだけで相応の工数がかかります。 ## ロックインを避けられる構造 もう1つの特徴です。 **LLMはOpenAI互換APIなら何でも接続可能。**各社のクラウドAPIから、ローカル実行のモデルまで選べます。 これが効くのは、コスト面です。 **ローカルモデルを使えばランニングコストをゼロ化できます。**監視や収集のような「軽いが高頻度」なタスクほど、この差が積み上がります。 ### 誠実な但し書き 調査中に見つかった、注目すべき記述があります。 **提供元は自社モデルについて「チャット/推論向けでツールコールのループには不向き」と公式に明言しています**（エージェント用途には非推奨）。 **エージェント基盤とモデルを分離して考える設計思想**が明確に示されています。自社製品を無条件に推さない姿勢は、判断材料として信頼できます。 ## 主な機能 - **永続メモリ＆スキル** — メモリ＝事実、スキル＝手順。類似タスク時に自動想起。オープン標準互換 - **スケジュール自動化** — 自然言語またはcron式で定期実行。結果を任意のチャネルへ配信 - **サブエージェント委譲** — 独立コンテキスト・制限付きツールセットを持つ子エージェントを生成（既定3並列） - **サンドボックス** — local / docker / ssh 等から選択。コンテナはread-onlyルートFS・全capability drop等でハードニング - **MCP接続** — 任意のMCPサーバーをstdio/HTTPで接続し、既存の社内ツールをハブ化できる - **チェックポイント/ロールバック** — ファイル変更前に自動スナップショット スキルの「progressive disclosure」によるトークン節約や、プロンプトキャッシュが常時ONで設定不要といった細部も作り込まれています。 ## 使い分けの判断軸 この調査が示す結論は明快です。 > **監視・収集・定例配信などの運用反復タスク → 常駐型エージェントに任せる**（ローカル/安価モデルでコスト最小） > **コードを書く・難しい判断の実装タスク → コーディングエージェント**（必要に応じてフロンティアモデル） 判断の根拠も整理されています。 - **コーディングエージェントのSDKで書く場合**：常駐・スケジューラ・チャネル接続・通知配信・記憶DBを自分で実装する必要がある。加えて**LLMのAPI従量課金が必ず発生する** - **常駐型が効く理由**：配管が設定だけで揃う／ローカルモデルでコストをゼロ化できる／マルチユーザー共有と権限分離が標準／モデル差し替えでロックインしない - **コーディングエージェントが勝つ場面**：タスクの中身が「コードを書く・直す・PRを出す」で、推論品質が成果を左右する用途 **「高頻度で軽いタスク」ほど、API従量課金が積み上がります。**ここがコスト構造の分かれ目です。 ## 懸念点 - **コーディング特化のIDE統合は専用ツールに一日の長がある** - **OSS常駐＝サーバー・セキュリティ・アップデート管理は自己責任** - 実機での精度・安定性・運用負荷は未実測 - ドキュメント上、Windows環境の記述に混在がある 2つ目が実務上の判断ポイントです。**本体が無料でも、運用の責任は自分側に来ます。** 安全設計の推奨も記録されています。**常駐運用では必ず許可リスト/ペアリングを設定し、承認スキップ系のオプションは信頼環境のみで使う。** ## 調査手法の発見 この検証は机上調査ですが、その手法自体に発見がありました。 **公式が `/llms.txt` と `/llms-full.txt`（全文ダンプ）を公開しており、AIエージェントによる調査が極めて容易でした。**SPA相手でも、公開のテキストダンプがあれば全機能を網羅できます。 ここから一般化できるTipsがあります。 **任意のサイトを調査する際は、まず `/llms.txt`・`/llms-full.txt`・`/sitemap.xml`・`/robots.txt` を確認すると、ブラウザ巡回せずに全体像を取得できる場合があります。** AIに読ませる前提のファイルを用意しておくことは、**提供する側にとっても調査される機会を増やす**ことになります。LLMO/AIOの観点でも参考になる実装です。 ## よくある質問 ### コーディングエージェントと何が違いますか？ **レイヤーが違います。**コーディングエージェントは「コードを書く本体」、常駐型エージェント基盤は「運用フレームワーク」です。常駐・cron・チャネル連携・記憶が標準で揃っている点が差になります。 ### 費用はかかりますか？ **本体はMITライセンスで0円です。**かかるのは接続したLLMのAPI課金のみで、ローカルモデルを使えばゼロ化も可能です。 ### どんなタスクに向いていますか？ **監視・収集・定例配信などの運用反復タスクです。**コードを書く・難しい判断が必要な実装タスクは、コーディングエージェントのほうが適しています。 ### 導入時の注意点は？ **OSS常駐なので、サーバー・セキュリティ・アップデート管理は自己責任になります。**常駐運用では許可リストとペアリングの設定が必須です。 ## まとめ - 常駐型エージェント基盤は**コーディングエージェントとレイヤーが違う。**比較軸を間違えない - 価値は**「運用の配管」が標準で揃っていること**——常駐・cron・チャネル連携・記憶 - **OpenAI互換APIなら何でも接続可能。**ローカルモデルでランニングコストをゼロ化できる - 提供元が**自社モデルを「エージェント用途には非推奨」と明言**している。基盤とモデルを分離する思想 - 使い分けは**運用反復タスク→常駐型、実装タスク→コーディングエージェント** - **本体無料でも運用責任は自分側**。許可リスト設定は必須 - 調査時は**`/llms.txt`・`/sitemap.xml`・`/robots.txt` を先に確認**すると全体像が速く取れる AIエージェントの選定では、何ができるかより「どの層のツールか」を見ると混乱しません。同じ名前でも、担当する範囲がまったく違うことがあります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAIエージェント導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## SNS自動投稿は個人でもできるか｜3媒体のAPI料金・審査要件を確定させる - URL: https://ai-katsu.jp/articles/sns-posting-api-survey - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-03T00:00:00+00:00 - Tools: Threads, X（旧Twitter） - Tasks: リサーチ・データ収集, 業務プロジェクト - Domain: マーケティング > Threads・X・LinkedInの投稿APIについて、料金・審査要件・個人での実用性を調査しました。LinkedInの個人投稿は審査不要・無料、XはURL付き投稿だけ約20倍という料金構造。3媒体共通でトークンが60日失効するため、更新バッチが自動化の生命線になります。 SNSへの投稿を自動化したい。しかし**「そもそも公式APIが個人に開放されているのか」**が分からないまま、手動運用が続いている——よくある状況です。 この調査では、3媒体の投稿APIについて**料金・審査要件・個人での実用性**を確定させました。結果、事前の想定と違っていた点が2つありました。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査日 | 2026年6月3日 | | 対象 | Threads API / X API v2 / LinkedIn Posts API | | 方針 | **スクレイピングは完全に除外**（規約上不可・ログイン必須のため）。公式APIのみで評価 | | 方法 | リサーチエージェント3並列で公式ドキュメント中心に調査 | > 料金・仕様は**2026年6月時点**のものです。この領域は変動が激しいため、実装前に必ず最新の公式情報をご確認ください。 ## 結論：3媒体すべてに道がある | 媒体 | 料金 | 個人の実用性 | 必須手続き | | --- | --- | --- | --- | | **Threads** | **無料** | ◎ | 開発者登録＋App Review＋連携アカウント | | X | **従量課金のみ**（無料枠廃止） | ○テキスト / △リンク | 登録＋OAuth2 User Context | | **LinkedIn** | **個人投稿は無料・審査不要** | ○ | 製品追加＋OAuth2 | ### 想定と違っていた2点 **① LinkedInは「そもそも使えない」と思っていたが、誤解だった。** **個人プロフィールへの投稿は審査不要・無料で利用できます。**審査が厳しいのは会社ページ投稿だけでした。 **② Xは従量課金だが、思ったより安い。** テキストのみなら**月30投稿で約$0.45**。コスト障壁は想定より低い水準です。 ## Xの落とし穴：URLを含めると20倍 この調査で最も実務的な発見です。 | 投稿種別 | 単価 | | --- | --- | | テキスト/メディア投稿（**URLなし**） | **$0.015 / 投稿** | | **URL含む投稿** | **$0.200 / 投稿** | | リプライ | $0.010 / 投稿 | **URL付き投稿は約20倍です。**月30投稿で比較すると、URLなし約$0.45に対しURL付きは約$6.00になります。 **ブログ記事のリンクを毎回貼る運用は、コストが急増します。** ### 回避策 **本文にリンクを入れず、投稿後にリプライ（$0.01）でリンクを返す形式にすると、最大1/20にコストを圧縮できる可能性があります。** $0.015（本文）+ $0.010（リプライ）= $0.025 で、$0.200と比べて大幅に安くなります。 **料金体系が運用フォーマットを決める**——という構造です。この単価差を知らずに設計すると、後から請求で気づくことになります。 ## 共通の生命線：トークンの60日失効 3媒体に共通する運用上の課題です。 **アクセストークンが60日で失効します。トークン自動更新バッチが自動化成功の生命線です。** Threadsについては、より厳しい条件があります。**長期トークンの有効期限は60日で自動更新なし。手動リフレッシュをバッチ化する必要があります。** **投稿機能を作り込んでも、2ヶ月後に静かに止まります。**最初にここを作り込むべきという指摘は、実務的に重要です。 実際、この調査では**「最大の隠れコストは金銭よりトークン更新・審査・認証フローの実装工数」**と結論づけています。 ## 媒体別の詳細 ### Threads - **料金は完全無料。**有料/従量課金プランなし - レート制限（24h）: **投稿250件 / 返信1,000件 / 削除100件** - できること: テキスト/画像/動画/カルーセル投稿、返信、引用、再投稿、削除、インサイト、Webhooks - **予約投稿はAPI非対応。**自前でキュー＋cron実装が必要 - **自分1人で使う場合も、投稿権限にはApp Reviewが必要** - Graph APIとは別建て。投稿は**コンテナ作成 → 公開の2ステップ** 無料枠が広い一方、**審査が必要な点と予約投稿非対応**が実装上のポイントになります。 ### X - **2026年2月6日に無料枠を廃止**し、従量課金へ全面移行 - レート制限: 投稿はユーザー単位100回/15分、アプリ単位10,000回/24h - 認証: **OAuth 2.0 User Context（必須）。App-Only不可** - スレッド連投◯、**予約投稿◯** - **従量課金にハードキャップなし → 支出上限を必ず設定する** 最後の項目は重要です。**上限を設定しなければ、不具合で連投したときに青天井で課金されます。** また、**2026年に2回の価格改定があり、料金は固定費として計画しにくい**という状況です。公式も最新確認を案内しています。 ### LinkedIn - 現行は Posts API。**旧APIはdeprecated**のため、新規実装では現行APIを使う - **個人プロフィール投稿: 製品をアプリに追加するだけで権限を取得でき、審査不要・無料** - **組織（会社ページ）投稿: 法人格・事業用メール必須の厳格な審査。**個人メールでは通過困難 - アクセストークン60日、リフレッシュトークン365日 - レート制限: メンバー単位150リクエスト/日 **個人と組織で難易度がまったく違います。**個人投稿は低〜中、会社ページは個人事業主には実質クローズドという評価です。 ## 着手順の推奨 1. **LinkedIn個人投稿**（無料・審査不要） 2. **Threads**（無料だがApp Review要） 3. **X**（従量課金・URL運用設計が要検討） **手続きの軽い順に着手する**のが合理的です。審査待ちで止まる可能性がある媒体を後回しにすれば、その間に他を進められます。 ## 設計上の指針 - **トークン自動更新バッチの共通設計を先に固める**（3媒体共通の課題のため） - **予約投稿は媒体横断のスケジューラを自前基盤側に持つ**——Threadsが非対応のため、媒体側の機能に依存しない設計が筋が良い - Xは本文URLを避けるか、リプライ方式に設計変更する - Xの支出上限を必ず設定する **媒体ごとの機能差を吸収する層を自前で持つ**という判断です。媒体を増やすときにも、この設計なら対応しやすくなります。 ## 未確認事項 - LinkedInで、単体の製品追加時にリフレッシュトークンが自動付与されるか - Threadsの投稿APIで、連携アカウントが今も必須か - 各媒体の審査の実所要日数（Threadsは公称2〜3日だが、初回却下で2〜3週間見込み） 最後の項目は計画に影響します。**審査は一度で通るとは限りません。**スケジュールには余裕が必要です。 ## よくある質問 ### LinkedInは個人でも使えますか？ **個人プロフィールへの投稿は審査不要・無料で使えます。**審査が厳しいのは会社ページ投稿だけで、こちらは法人格・事業用メールが必須です。 ### Xの自動投稿はいくらかかりますか？ **テキストのみなら月30投稿で約$0.45です。**ただしURLを本文に含めると$0.20/投稿となり、月30投稿で約$6.00になります。リプライでリンクを返す形式にすると圧縮できます。 ### 自動化で最も手間がかかるのは？ **トークンの自動更新です。**3媒体すべてでアクセストークンが60日で失効するため、更新バッチが自動化成功の生命線になります。 ### 予約投稿はできますか？ **媒体によります。**XはAPIで対応していますが、ThreadsはAPI非対応です。媒体横断で運用するなら、スケジューラを自前基盤側に持つ設計が確実です。 ## まとめ - **3媒体すべてに公式の投稿APIがあり、個人でも自動化の道がある** - **LinkedInの個人投稿は審査不要・無料。**「使えない」は誤解 - Xは従量課金だが**テキストのみなら月数十円〜数百円**。ただし**URL付きは約20倍** - 回避策は**本文にリンクを入れず、リプライでリンクを返す** - **3媒体共通でトークンが60日失効。**更新バッチが自動化の生命線 - **予約投稿は媒体横断のスケジューラを自前で持つ**（Threadsが非対応のため） - 着手順は**LinkedIn → Threads → X**（手続きの軽い順） - Xの**支出上限は必ず設定する**（ハードキャップがないため） 自動化の検討では、技術的な実装より先に「使えるのか・いくらかかるのか」を確定させると計画が立ちます。料金体系が運用のフォーマットを決めることもあります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 取得の段階で整形する｜Cloudflare Browser Renderingのエンドポイント使い分け - URL: https://ai-katsu.jp/articles/cloudflare-browser-rendering - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-03T00:00:00+00:00 - Tools: Cloudflare, n8n - Tasks: リサーチ・データ収集, ツール検証 > Browser Renderingの5つのエンドポイントを軽い順に実行し、何が取得できるかを比較しました。/markdownはDOM全取得よりトークン消費が圧倒的に少なく、/jsonなら取得と構造化を1リクエストで完結できます。SPAで結果が空になる落とし穴と対処もまとめています。 Webページから情報を取るとき、多くの場合はHTMLを丸ごと取得してから処理します。しかしAIに渡す前提なら、**その時点で大量のノイズを含んだトークンを消費している**ことになります。 この検証では、Cloudflare Browser Renderingの各エンドポイントを**軽い順に叩いて**、何が取得できるかを比較しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年6月3日〜（検証中） | | 対象 | Cloudflare Browser Rendering（Browser Run）REST API | | やりたかったこと | ニュース一覧 → 記事URL収集 → 本文取得というパイプラインを、どのエンドポイントの組み合わせで最小コストに組めるか見極める | | 方法 | 同一ページに対し、5つのエンドポイントを軽い順に実行して比較 | | 結果 | **各エンドポイントとも取得成功** | > 外部サイトのデータ取得は、対象サイトの利用規約およびrobots.txtを尊重して行う必要があります。 ## 結論：用途別に最小コストの取得手段を選べる 5つのエンドポイントが、それぞれ異なる粒度で結果を返します。 | エンドポイント | 用途 | 取得物 | | --- | --- | --- | | **`/links`** | ページ内のリンク一覧（**最軽量**） | 全リンクURLの配列 | | **`/markdown`** | 本文をMarkdownで取得（**LLMに優しい**） | ノイズ除去済みMarkdown | | `/content` | レンダリング後のフルHTML | 実際のDOM全体 | | **`/json`** | **AIで構造化データ抽出** | 整形済みJSON | | `/scrape` | CSSセレクタで特定要素だけ抽出 | 指定セレクタの要素 | すべて `POST .../browser-rendering/{endpoint}` という同一形式で、Bodyに対象URLを渡すだけです。**学習コストは低く、用途に応じて切り替えられます。** ## `/markdown` がトークン削減に効く 実務で最も効く発見です。 **`/markdown` はHTMLのノイズを除いたMarkdownを返します。DOM全取得よりトークン消費が圧倒的に少なくなります。** 実際に一覧ページで試したところ、**記事タイトル・日付・URL・カテゴリがほぼ構造を保ったまま取得できました。** HTMLには、スクリプトタグ、スタイル、属性、ナビゲーション、フッターなど、内容とは関係のない要素が大量に含まれます。**それをそのままAIに渡すと、読ませたい部分より周辺のほうが多くなります。** なお `/content` は実際のDOMが全て取得できましたが、**コンテキストが過大になるため、この検証ログでは結果の掲載を割愛しています。**それだけの分量になるということです。 ## 2つのパイプライン構成 目的に応じて、2つの現実的な構成があります。 ### ① 2段構成 ``` /links でリンク収集 ↓ /markdown で本文取得 ``` **`/links` は最軽量で、ページ内の全リンクURLが配列で返ります。**24時間以内の記事に絞り込む前段として最適です。 一覧ページ全体を取得せず、**URLだけ取ってから対象を絞り、必要な記事だけ本文を取る**——この順番でコストが下がります。 ### ② 一発で構造化 **`/json` は背後でWorkers AIが動き、構造化済みJSONを返します。プロンプトで抽出項目を指定できます。** これが決まれば、**後段のワークフローツール側でLLM処理を省略できる可能性**があります。取得と構造化が1回のリクエストで完結します。 **「取得してからAIで整形する」を「取得時点で整形させる」に変えられる**という発想です。 ## SPAでの落とし穴 実装上の注意点です。 **JavaScript重め・SPAのページでは、デフォルトのページ読み込み判定だと中身が空・不完全になることがあります。** 対処は `gotoOptions.waitUntil` を `networkidle0` / `networkidle2` に設定することです。 **「取得できたけど中身が空」という症状が出たら、まずここを疑います。**エラーにならず成功扱いで空が返るため、気づきにくい部分です。 ## それぞれの使いどころ | やりたいこと | エンドポイント | | --- | --- | | 一覧からURLだけ集めたい | **`/links`** | | 記事本文をAIに読ませたい | **`/markdown`** | | 特定の要素だけ確実に取りたい | `/scrape`（CSSセレクタ指定） | | 取得と構造化を1回で済ませたい | **`/json`**（プロンプトで項目指定） | | DOM全体が必要 | `/content` | **目的が決まっていれば、フルHTMLを取る必要はほとんどありません。** ## 懸念点 - **SPAでは `waitUntil` の調整が必要**で、設定を誤ると中身が空・不完全になる - **対象ページのDOM構造変更によりCSSセレクタが壊れる可能性**（`/scrape` 使用時） - Cloudflare（Workers / Workers AI）への依存 2つ目は構造的な問題です。**セレクタ指定は正確ですが、相手のページ構造に依存します。**壊れる前提で、代替手段を用意しておく必要があります。 その点、`/markdown` や `/json` は構造変更に比較的強くなります。**「どこを取るか」ではなく「何が欲しいか」で指定するため**です。 ## よくある質問 ### どのエンドポイントを使うべきですか？ **目的によります。**URLだけなら `/links`、AIに読ませる本文なら `/markdown`、取得と構造化を1回で済ませたいなら `/json` です。フルHTMLが必要なケースは限られます。 ### なぜMarkdownで取るのですか？ **HTMLのノイズを除いたテキストが返るため、トークン消費が圧倒的に少なくなります。**一覧ページでも、タイトル・日付・URL・カテゴリの構造を保ったまま取得できました。 ### 取得結果が空になります **JavaScript重めのページで、読み込み完了前に取得している可能性があります。**`gotoOptions.waitUntil` を `networkidle0` / `networkidle2` に設定してください。 ### AIによる構造化は使えますか？ **`/json` でプロンプトを指定して抽出できます。**これが機能すれば、後段のワークフローでLLM処理を省略できる可能性があります。 ## まとめ - 用途別に5つのエンドポイントがあり、**目的に応じて最小コストの取得手段を選べる** - **`/markdown` はDOM全取得よりトークン消費が圧倒的に少ない。**構造も保たれる - パイプラインは**「`/links` でURL収集 → `/markdown` で本文取得」の2段構成**が効率的 - **`/json` なら取得と構造化を1リクエストで完結**でき、後段のLLM処理を省略できる可能性がある - **SPAでは `waitUntil` の調整が必要。**設定を誤ると空の結果が成功扱いで返る - CSSセレクタ指定は正確だが**相手のDOM構造変更に弱い** AIに渡すデータは、渡す前の整形でコストが決まります。取得の段階で必要な形にできれば、後段の処理そのものが不要になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の情報収集・業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIエージェント基盤にサーバーレスが向かない理由｜14構成を比較して分かったこと - URL: https://ai-katsu.jp/articles/multi-agent-infra-comparison - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-03T00:00:00+00:00 - Models: Claude Code - Tools: Browser Use, Google Cloud - Tasks: AIエージェント, 業務プロジェクト - Domain: 社内基盤・インフラ > 複数のAIエージェントを動かすインフラを14パターン横断比較しました。作りたいのは軽量APIサーバーではなく「リモートに置くAI実行端末」——CLIエージェントはOS・シェル前提のため、ステートレス短時間処理のサーバーレスとは思想が噛み合いません。満たすべき6条件と推奨スペックをまとめています。 AIエージェントを動かすインフラを選ぶとき、普通のWebアプリと同じ基準で考えると失敗します。**作りたいのは「軽量APIサーバー」ではなく「リモートに置くAI実行端末」**だからです。 この検証では、その前提の違いを起点に、**14の構成パターンを横断比較**しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年6月3日〜（Phase 0：構成整理のみ） | | 目的 | 複数のAIエージェントを実行できる環境を作る場合、どのインフラ構成が考えられるかを整理する | | 比較対象 | VPS / 物理PC・ミニPC / AWS各種 / GCP各種 / PaaS各種の**14パターン** | | 第一候補 | **VPS + Docker Compose** | | 状況 | 構成比較まで完了。本番構築は未着手 | ## 結論：サーバーレスは思想が噛み合わない この検証で最も重要な指摘です。 **CLIエージェント系は「OS・シェル・ファイルシステム・作業ディレクトリがありCLIを起動できる」世界観が前提です。これはVPS・VM・物理PC・コンテナホストと相性が良く、ステートレス短時間処理が得意なサーバーレスとはやや噛み合いません。** APIの中で何が動くのかを列挙すると、この違いがはっきりします。 - CLI実行 - 自律ブラウザ操作 - Chromium起動 - 長めのLLM推論 - 複数ステップのエージェントループ - ファイル生成・作業ログ保存 **サーバーレスに寄せすぎると起きる問題も具体的です。** メモリ不足、Chromiumが起動しない、タイムアウト、コールドスタートが重い、作業状態を残しにくい、複数エージェントの干渉、デバッグ困難、SSHで中身を見られない——といった不整合が出やすくなります。 ## 満たすべき条件 この検証では、問題設定を「クラウドに何を置くか」から**「AIエージェント用の実行端末をどう設計するか」**へ再定義しています。 満たすべき条件は6つです。 1. **Dockerで持ち運べる** 2. **HTTPで外部から呼べる** 3. **役割ごとに分離できる** 4. **ログと状態を追える** 5. **ブラウザ操作に耐えるスペック** 6. **必要時にRDP・SSHで中身を見られる** 最後の1つが、サーバーレスでは満たしにくい条件です。**エージェントが何をしているか分からなくなったとき、中に入って確認できるかどうかは運用の成否を分けます。** ## 構成パターンの比較 | パターン | 月額 | 自由度 | デバッグ | 総合コメント | | --- | --- | --- | --- | --- | | **VPS** | 低〜中 | 高 | 高 | **最もバランス良・第一候補** | | **物理PC / ミニPC** | 低（電気代） | **最高** | **最高** | 自分用の実験基盤として有力 | | クラウドVM（EC2 / Compute Engine） | 中 | 高 | 高 | そのクラウド前提なら現実的 | | **コンテナオーケストレーション（Fargate等）** | 中〜高 | 中 | 中 | **本番の役割別分離の本命** | | サーバーレスコンテナ（Cloud Run等） | 低〜中 | 中 | 中 | 技術的には良いが制約あり | | **関数系サーバーレス（Lambda等）** | 安い | **低** | **低** | **自律ループには窮屈・見送り寄り** | | 各種PaaS | 中 | 中 | 中 | 早く試す用。ブラウザ操作には弱いものも | **関数系サーバーレスの評価が明確です。**コストは安いものの、自由度とデバッグ性が低く、自律ループには向きません。 ## 推奨スペックの目安 | 用途 | 最低 | 推奨 | 余裕 / 複数同時 | | --- | --- | --- | --- | | CLIエージェント単体（推論はクラウド側） | 2 vCPU / 4GB | 2〜4 vCPU / 8GB | — | | メモリ・ツール・ブラウザ込みのエージェント | 2 vCPU / 4GB | 4 vCPU / 8GB | 4〜8 vCPU / 16GB | | **Playwright / Chromium込み（最も重い）** | 2 vCPU / 4GB | 4 vCPU / 8GB | **4〜8 vCPU / 16GB以上** | | 役割別エージェント複数 | — | 8GB | 16GBあると安心 | ブラウザ操作が最も重い要因です。 **Chromiumを使うためCLIエージェントよりメモリを食います。動的・SPA・ログイン付きサイトでは4GBはカツカツになりうる**という評価です。 対策も具体的です。**役割別に複数動かす場合、各エージェントが常時ブラウザを起動するのは避け、ブラウザ操作だけ専用コンテナに切り出すか、ジョブ実行時のみChromiumを起動する**設計にします。 ## 同期型から始めて、重くなったら非同期型へ アーキテクチャの選択についても整理されています。 | 方式 | 構成 | 特性 | | --- | --- | --- | | **同期型** | `POST /run` → 実行 → 結果JSON返却 | **構成がシンプルでPoC向き。**ただし処理が長いとタイムアウトしやすい | | **非同期型** | `POST /jobs` → job\_id即返し → 裏で実行 → 完了後Webhookへ | **長時間処理に強く実務運用向き。**ただしjob\_id管理・キュー・再実行設計が必要 | **最初から非同期にすると、作るものが増えます。**まず同期型で動かし、タイムアウトが問題になってから非同期に移すという順番が現実的です。 ## この検証の位置づけ ログの冒頭に、明確な但し書きがあります。 **「今すぐ本番構築するためではなく、後から再検討するときに壁打ち結果を引き出せるようにするための整理メモ」** これは記録として重要な姿勢です。**決めきらないまま整理を残しておくと、実際に必要になったときの判断が速くなります。** あわせて、役割別エージェント組織の設計案、セキュリティ設計、ロードマップ、再検討時のチェックリストも整理されています。 ## 選定の判断軸 この比較から導ける判断軸を整理すると、こうなります。 - **ブラウザ操作を含むか** — 含むならメモリ要件が跳ね上がる - **デバッグのために中に入る必要があるか** — あるならSSH可能な環境 - **状態を保持する必要があるか** — あるならステートレス前提の環境は不向き - **役割別に分離したいか** — したいならコンテナオーケストレーション - **コストを固定にしたいか** — したいならVPSの月額固定 **「安いから」でサーバーレスを選ぶと、動かないものを動かそうとして時間を失います。** ## よくある質問 ### なぜサーバーレスでは難しいのですか？ **CLIエージェントはOS・シェル・ファイルシステムがある前提で動くためです。**メモリ不足、Chromiumが起動しない、タイムアウト、状態を残しにくい、中を見られない——といった問題が出ます。 ### どの構成から始めるべきですか？ **VPS + Docker Composeが第一候補です。**月額固定でコストが読め、SSHでログを追え、役割別エージェントを増やしやすくなります。自分用の検証なら物理PC/ミニPCも有力です。 ### どのくらいのスペックが必要ですか？ **ブラウザ操作を含むなら4 vCPU / 8GBが推奨です。**複数のエージェントを同時に動かすなら16GBあると安心です。動的・ログイン付きサイトでは4GBはカツカツになります。 ### 最初から非同期型にすべきですか？ **まず同期型で始めるほうがシンプルです。**処理が長くタイムアウトが問題になってから、非同期型へ移行します。 ## まとめ - 作りたいのは軽量APIサーバーではなく**「リモートに置くAI実行端末」** - **CLIエージェントはOS・シェル前提。ステートレス短時間処理のサーバーレスとは思想が噛み合わない** - 満たすべき条件は**Docker化・HTTP呼び出し・役割分離・ログ追跡・ブラウザ耐性・SSH可能**の6点 - 第一候補は**VPS + Docker Compose**。本番の役割別分離ならコンテナオーケストレーション - **ブラウザ操作が最もメモリを食う。**専用コンテナに切り出すか、ジョブ実行時のみ起動する - アーキテクチャは**同期型から始め、重くなったら非同期型へ** - **決めきらないまま整理を残しておく**と、必要になったときの判断が速くなる インフラ選定では、動かすものの性質を先に言語化すると選択肢が絞れます。同じ「APIを立てる」でも、中で何が動くかによって適した環境は変わります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAI基盤づくりを支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## $20プランで$132請求された原因｜Vercelのコスト超過はビルド回数だった - URL: https://ai-katsu.jp/articles/vercel-cost-build-management - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-02T00:00:00+00:00 - Tools: Vercel, Cloudflare, GitHub - Tasks: 開発・エンジニアリング, ツール検証 > Proプラン$20/月に対し実請求$132.62、超過約$112。内訳を分解すると、Build CPU Minutesが全体の約90%を占めていました。原因は常時起動コストではなく開発の進め方。Ignored Build Stepによる止血、ビルドマシン種別の確認、上限設定の注意点までまとめています。 契約プランは$20/月。しかし実際の請求は**$132.62**——超過分は約$112でした。 この検証では、その原因を特定し、対策を実施しました。**主因はサーバーレス構成の常時起動コストではなく、ビルド回数の多さでした。** ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年6月2日〜（対応継続中） | | 対象 | Vercel（Proプラン $20/月） | | 問題 | **実請求 $132.62（On-Demand超過 約$112）** | | 主因 | **Build CPU Minutes が全体の約90%** | | 対応 | Ignored Build Step で production 以外のビルドを停止 | | 状況 | 止血対応は完了、運用フロー整備が残課題 | ## 結論：ビルド回数が9割を占めていた 請求の内訳を確認したところ、構造がはっきりしました。 | 項目 | 金額 | 割合 | | --- | --- | --- | | **Build CPU Minutes** | **$145.43** | **約90%** | | Fast Origin Transfer | $2.53 | 少額 | | Fluid Active CPU | $1.80 | 少額 | **「サーバーレスだから実行コストが高いのでは」という想定は外れました。**実行時のCPU課金（Fluid Active CPU）は$1.80で、超過分としては軽微です。 膨らんでいたのは**ビルド**でした。 ## なぜビルドが積み上がるのか デフォルトの挙動が原因です。 **GitHub連携では、デフォルトで全ブランチへのpush・PR作成時に自動でデプロイ（ビルド）が実行されます。** つまり、こうなります。 - featureブランチにpushするたびにビルド - PRを作るたびにビルド - **mainへの細かいマージが多いほど、そのたびに本番ビルドが走る** この検証では、**featureブランチ運用が確立されておらず、mainへの細かいPR・マージが多い**状態でした。開発の進め方が、そのまま課金に反映されていたことになります。 ## 対処①：production以外のビルドを止める 最も効果の大きい対応です。 **Ignored Build Stepを「Only build production」に設定**しました。 ``` if [[ "$VERCEL_ENV" == "production" ]]; then exit 1; else exit 0; fi ``` これにより、featureブランチや未割り当てブランチへのpush/PRではビルドが走らなくなります。 ここで押さえるべき仕様の違いがあります。 **キャンセルされたビルドはデプロイメントクォータにカウントされますが、スキップ（ビルド未実行）はCPU消費が発生しません。** 組み込みのオプションによるスキップと、bashコマンドでキャンセルする方式は**仕組みが違います。**コスト削減が目的なら、スキップさせる必要があります。 ## 対処②：ビルドマシンの種別を確認する もう1つの大きなコスト要因です。 | マシン種別 | 単価 | | --- | --- | | Turbo（固定） | $0.126/分 | | **Elastic（自動スケール）** | **$0.0035/CPU分から** | **多くのプロジェクトでコストが半減以上します。** 新規チームではElastic Build Machinesがデフォルトですが、**以前から使っているプロジェクトはTurbo固定のままになっている可能性があります。**確認する価値のある設定です。 ## 止血だけでなく上限を設ける この検証で最も重要な指摘かもしれません。 **Spend Managementを設定しない限り、On-Demand超過は上限なく課金され続けます。** 対策として、50%/75%/100%での通知と、上限到達時にproductionを自動停止する設定が可能です。新規Proチームは$200がデフォルト予算になっています。 ただし注意点があります。 **チェックは数分ごとのため、上限到達後も数分は課金が継続しうる。絶対上限より低い値を設定するのが安全です。** **「上限を設定したから絶対に超えない」ではありません。**余裕を持った値にしておく必要があります。 ## その他のコスト削減策 - **`vercel.json` でブランチ単位制御** — `git.deploymentEnabled` でパターン指定のデプロイ無効化 - **Turborepo Remote Cache** — モノレポなら**追加費用ゼロでビルド時間を最大85%削減**（全プラン無料） - **On-Demand Concurrent Buildsを「1ブランチ1ビルド」に制限** — 並行ビルドの無駄を抑制 - **Active CPU課金の理解** — I/O待ち中は課金されないため、Cache-ControlやISRの設定でActive CPU消費を削減できる Remote Cacheは全プラン無料です。**モノレポ構成なら、設定するだけで効果が出ます。** ## 他プラットフォームとのコスト比較 | プラットフォーム | ビルド | 帯域 | 備考 | | --- | --- | --- | --- | | Vercel | $0.0035/CPU分〜（Elastic） | $0.15/GB（超過） | **Next.js最適化が最強、コストは高め** | | **Cloudflare Pages** | 月500ビルド（無料）、実質無制限に近い | **Egress無料** | **コスト最安、帯域課金なし** | | Netlify | 100分/月（無料） | 100GB/月（無料） | 2025年に無料枠を300分→100分へ削減 | | Render | 月500ビルド分（無料） | 100GB/月（無料） | フルスタック対応、Next.js最適化は弱い | 判断の軸は明確です。 **Next.js以外（Astro等）なら、Cloudflare Pagesへの移行でビルド・帯域コストをほぼゼロに近づけられます。** 逆にNext.jsを使うなら、統合・DX・Preview体験の価値とコストを天秤にかけることになります。 ## トレードオフ ビルドを止めることには代償があります。 **featureブランチ単位のPreview URLが発行されなくなります。**動作確認はdevelop/mainマージ後に行う運用へ変わります。 この検証では、**現状Preview確認が運用に組み込まれていないため実害なし**と判断しました。 **使っていない機能のためにコストを払っていた**——という構造です。設定を見直す前に、実際に使っているかを確認する価値があります。 ## 対応ロードマップ | 優先度 | 内容 | 状態 | | --- | --- | --- | | 高 | Ignored Build Stepを「Only build production」に設定 | **完了** | | 高 | mainへの直接プッシュ防止 | **完了** | | 中 | Spend Limitをハードリミットに変更 | 今後 | | 低 | featureブランチ運用へ移行（作業者 → feature/\* → develop → main） | ゆくゆく | **止血（ビルド停止）を先に、体質改善（運用フロー）を後に**という順番です。課金は待ってくれないため、この順序が現実的です。 ## よくある質問 ### なぜ請求が膨らんだのですか？ **ビルド回数の多さが主因です。**Build CPU Minutesが全体の約90%を占めていました。実行時のCPU課金は$1.80と軽微でした。 ### すぐにできる対策は？ **Ignored Build Stepを「Only build production」に設定してください。**featureブランチやPRでのビルドが走らなくなります。あわせて、ビルドマシンがTurbo固定になっていないか確認すると効果が大きくなります。 ### 上限を設定すれば安心ですか？ **チェックが数分ごとのため、上限到達後も数分は課金が継続しうる点に注意してください。**絶対上限より低い値を設定するのが安全です。 ### 他プラットフォームへの移行は有効ですか？ **Next.js以外を使っているなら有効です。**Cloudflare Pagesならビルド・帯域コストをほぼゼロに近づけられます。Next.jsを使う場合は、統合とDXの価値との比較になります。 ## まとめ - 超過の主因は**常時起動コストではなくビルド回数**。Build CPU Minutesが約90% - デフォルトでは**全ブランチへのpush・PRでビルドが走る** - **Ignored Build Stepで production 以外をスキップ**する。キャンセルとスキップは仕組みが違う - **Turbo固定とElasticでは単価が大きく違う**（$0.126/分 vs $0.0035/CPU分〜） - **上限設定がなければ超過は無制限に続く。**ただし到達後も数分は課金されうる - モノレポなら**Remote Cacheが無料でビルド時間を最大85%削減** - **使っていない機能（Preview URL）のためにコストを払っていないか**を確認する クラウドサービスのコストは、機能の使い方ではなく開発の進め方に反映されます。請求内訳を分解すると、どの習慣が効いているかが見えてきます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制とインフラ運用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## WordPressの/blogだけVercelで配信する方法｜Cloudflare Worker設定手順 - URL: https://ai-katsu.jp/articles/cloudflare-worker-vercel-subpath - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-01T00:00:00+00:00 - Tools: Cloudflare, Vercel - Tasks: 開発・エンジニアリング, ツール検証 > 既存のWordPressサイトはそのままに、/blog のようなサブパスだけをVercelの静的サイトで配信する方法を解説します。Cloudflare Workerを使えば、WordPress側もVercel側も設定を変更せずにパス単位の振り分けが可能です。ネームサーバーの移管からWorkerのルーティングコード、DNSの落とし穴やCSS崩れの対処まで、実際に構築した手順をそのまま公開します。 「既存のWordPressサイトはそのまま残したい。でも、新しく作るブログやオウンドメディアだけはNext.jsで作ってVercelに置きたい」——このリクエストは実務で非常によく発生します。しかも**サブドメイン（blog.example.com）ではなく、サブパス（example.com/blog）で配信したい**というケースがほとんどです。 この記事では、Cloudflare Workerを使って**WordPress側もVercel側も設定を一切変更せずに**、URLのパス単位でリクエストを振り分ける方法を、実際に構築した手順そのままで解説します。ネームサーバーの移管からWorkerのルーティングコード、つまずきやすいDNSトラブルやCSS崩れの対処までを一通りカバーします。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年6月 | | 使用ツール | Cloudflare Workers / Vercel / WordPress | | やりたかったこと | 既存のWordPressサイトを残したまま、`example.com/blog` だけをVercelの静的サイトで配信する | | 結論 | Cloudflare Workerを1つ作るだけで実現できた。WordPress側・Vercel側の設定変更は不要 | | 費用 | Cloudflareの無料プランの範囲内 | | つまずいた点 | DNS移管時のMXレコード消失、Next.jsの `/_next/` アセットが404になりCSSが崩れる | ## 結論：Cloudflare Worker 1つでサブパス振り分けは完結する 先に結論を書きます。**example.com/blog だけをVercelに、それ以外をWordPressに振り分ける構成は、Cloudflare Workerを1つ作るだけで実現できます。**踏み台としてのCloudflare Pagesも、WordPress側のリバースプロキシ設定も、Vercel側のドメイン設定変更も必要ありません。 ポイントは次の2点です。 - **DNSはIPアドレスまでしか届けられない**。「/blogだけ別サーバー」という*パス単位*の振り分けはDNSの守備範囲外で、これはCloudflare Workerの仕事になります - **Workerにはカスタムドメインを直接紐づけられる**。Settings → Domains & Routes から example.com をWorkerに割り当てれば、全リクエストがWorkerを経由します > この構成は、WordPressで運用中の企業サイトに、Next.jsで作った高速なオウンドメディアを後から合流させたい場合の定番パターンです。 ## なぜサブドメインではなくサブパスで配信するのか **サブパス（example.com/blog）での配信が選ばれる最大の理由は、ドメインの評価を1つに集約できるからです。** 検索エンジンは blog.example.com と example.com を、原則として**別サイト**として扱います。せっかく本体サイトが積み上げた被リンクやドメインの評価は、サブドメインのメディアにはそのまま引き継がれません。一方サブパスであれば同一サイト内のコンテンツとして扱われるため、本体サイトの評価を土台にした状態でメディアを立ち上げられます。 | 構成 | URL例 | ドメイン評価 | 構築の難易度 | | --- | --- | --- | --- | | サブドメイン | blog.example.com | 本体と分離されやすい | 低（DNSのCNAME1本） | | **サブパス** | **example.com/blog** | **本体に集約できる** | 中（プロキシが必要） | サブパス構成は「やりたいけれど、技術的にどう実現するかで詰まる」典型例です。その解決策が、これから解説するCloudflare Workerによるプロキシです。 ## 全体の構成イメージ 完成後の構成は次の図の通りです。ユーザーからのリクエストは必ずCloudflare Workerを通り、Workerがパスを見てWordPressとVercelのどちらに転送するかを決めます。 ![Cloudflare WorkerがリクエストをWordPressサーバーとVercelにパス単位で振り分ける全体構成図](/assets/images/column/cloudflare-vercel-subpath-proxy.webp) ``` ユーザー ↓（DNS解決 → CloudflareのIPが返る） Cloudflare Worker（example.com に直接紐づけ） ├── /blog, /blog/*, /_next/* → Vercel（静的サイト） └── それ以外 → WordPressサーバー（さくら / Xサーバー等） ``` 設定は次の4ステップに整理できます。 1. レジストラのネームサーバーをCloudflareに変更する 2. Cloudflare DNSでA / MX / TXTレコードを確認・整備する 3. Workerを作成し、Custom Domainで example.com を直接紐づける 4. Workerにルーティングコードを書いてデプロイする ## Step1｜Cloudflareにドメインを追加する ### アカウントを作成する [Cloudflare公式サイト](https://cloudflare.com)から「Sign Up」でメールアドレスとパスワードを登録します。**プランはFreeで問題ありません。**今回の構成に必要な機能はすべて無料枠で使えます。 ### ドメインを追加する 1. ダッシュボードから「Add a Site」を選択 2. ドメイン名（例：`example.com`）を入力 3. プランはFreeのまま続行 4. CloudflareがDNSレコードを自動スキャンして取り込む この自動スキャンで既存のレコードが引き継がれますが、**完全ではありません。**次のStepで必ず中身を確認します。 ## Step2｜ネームサーバーをCloudflareに変更する ドメイン追加後の画面に、Cloudflareが指定する2つのネームサーバーが表示されます。 ``` xxx.ns.cloudflare.com yyy.ns.cloudflare.com ``` この値を、ドメインを取得したサービス側の管理画面で設定します。 | サービス | 設定場所の目安 | | --- | --- | | お名前.com | ドメイン設定 → ネームサーバーの変更 | | さくらインターネット | ドメインメニュー → ネームサーバー設定 | | Xサーバー | サーバーパネル → ドメイン設定 | > **反映には最大48時間かかります。**Cloudflareのダッシュボードに「有効化されました」と表示されれば完了です。作業は余裕を持ったスケジュールで進めてください。 ## Step3｜DNSレコードを確認・整備する **この記事で最も事故が起きやすいのがこのStepです。**ネームサーバーの移管が完了したら、Cloudflareのdns管理画面でレコードを1つずつ確認します。 | 種別 | 名前 | 値 | プロキシ（オレンジ雲） | 用途 | | --- | --- | --- | --- | --- | | A | `@`（ルート） | WordPressサーバーのIP | オン | WordPressへの通信 | | A | `www` | WordPressサーバーのIP | オン | wwwアクセス | | MX | `@` | メールサーバー | **オフ** | メール配送 | | TXT | `@` | SPF / サーチコンソール等 | — | 各種認証 | ### 特に注意すべき2つのレコード - **MXレコード**：自動スキャンで取り込まれているか必ず確認してください。ここが消えていると**メールが一切届かなくなります**。またMXレコードはプロキシを**オフ**にする必要があります - **TXTレコード**：Google Search Consoleの所有権確認やSPF・DKIMの設定が引き継がれているか確認します。消えるとメールの到達率低下やSearch Consoleの計測断につながります > **移管前に、現在のDNSレコード一覧のスクリーンショットを必ず撮っておいてください。**何かが消えたときに、元の値がわからないと復旧できません。 ### WordPressサーバーのIPアドレスの調べ方 さくらインターネットやXサーバーなどのサーバー管理画面で、「サーバー情報」または「IPアドレス」の項目に記載されています。 ## Step4｜Workerを作成しカスタムドメインを紐づける **Cloudflare Workerとは、Cloudflareのエッジ（世界中の拠点）でリクエストを受け取り、任意のJavaScriptを実行できる仕組みです。**今回はこれを「リクエストの交通整理役」として使います。 ### Workerを新規作成する 1. Cloudflareダッシュボード → **Workers & Pages** 2. 「Create」→「Create Worker」 3. 名前をつける（例：`blog-proxy`） 4. デフォルトのコードのまま、いったん「Deploy」 ### カスタムドメインを直接紐づける 1. 作成したWorkerを開き、「Settings」タブへ 2. 「Domains & Routes」セクションの「+ Add」をクリック 3. モーダルで **「Custom Domain」** を選択 4. `example.com` を入力して追加 RouteとCustom Domainの2択が表示されますが、今回は**Custom Domainを選んでください。**違いは次の通りです。 | 方式 | 挙動 | 今回の適性 | | --- | --- | --- | | **Custom Domain** | ドメインまるごとWorkerに紐づける | **適する**（Worker内でパス判定するため） | | Route | `example.com/blog*` のようにパターンで制御 | 今回は不要 | 追加後、CloudflareのDNS管理画面にWorker向けのレコードが自動で追加されているか確認しておきます。 ## Step5｜振り分けロジックを実装する Workerの「Edit Code」を開き、以下のコードを貼り付けます。 ``` const BLOG_ORIGIN = 'https://your-app.vercel.app'; // ← VercelのURLに変更 function isVercelPath(path) { return path === '/blog' || path.startsWith('/blog/') || path.startsWith('/_next/') // Next.jsのCSS・JS || path.startsWith('/favicon'); // ファビコン } export default { async fetch(request) { const url = new URL(request.url); const path = url.pathname; if (isVercelPath(path)) { // /blog プレフィックスを除いてVercelに渡す const stripped = path.startsWith('/blog') ? (path.replace(/^\/blog/, '') || '/') : path; const target = new Request( BLOG_ORIGIN + stripped + url.search, request ); target.headers.set('Host', 'your-app.vercel.app'); // ← Vercelのホスト名 target.headers.set('X-Forwarded-Host', 'example.com'); // ← 自分のドメイン return fetch(target); } // /blog 以外はWordPressへ通常どおり転送 return fetch(request); } }; ``` 自分の環境に合わせて変更するのは、次の3か所だけです。 1. `BLOG_ORIGIN` にVercelのデプロイURL 2. `Host` ヘッダーにVercelのホスト名 3. `X-Forwarded-Host` に自分のドメイン `/_next/` の条件が入っている点が重要です。Next.jsはCSSやJavaScriptを `/_next/static/...` という**/blogを含まないパス**から読み込むため、この条件がないとアセットがWordPress側に流れて404になります。 書き換えたら「Deploy」して完了です。 ## Step6｜動作確認とCSS崩れのチェック デプロイ後、次の3つのURLを開いて期待どおりに表示されるか確認します。 | URL | 期待する結果 | | --- | --- | | `example.com/` | WordPressのトップページ | | `example.com/blog` | Vercelの静的サイト | | `example.com/blog/post-1` | Vercelの個別ページ | ページは表示されるのにデザインが崩れている場合、原因はほぼ**Next.jsの静的アセットが404になっていること**です。ブラウザの開発者ツールのNetworkタブで `/_next/static/...` のリクエストを確認し、404になっていれば `isVercelPath` に `/_next/` の条件が入っているかを見直して再デプロイしてください。 ## つまずきやすい5つのポイントと対処法 | 症状 | 原因 | 対処 | | --- | --- | --- | | WordPressも含め全部Vercelに飛ぶ | AレコードをVercelのIPに向けてしまった | AレコードをWordPressサーバーのIPに戻す | | `/blog` が404になる | Workerのパスマッチ、またはCustom Domain未設定 | `isVercelPath` の条件と Settings → Domains & Routes を確認 | | CSSが崩れる | `/_next/` パスがVercelに流れていない | `isVercelPath` に条件を追加して再デプロイ | | メールが届かなくなった | MXレコードが移管時に消えた | Cloudflare DNSにMXレコードを再追加 | | 変更が反映されない | DNSのキャッシュ | 最大48時間待つ／ブラウザキャッシュをクリア | ## DNSレコード用語チートシート DNS移管の作業中に迷わないよう、登場するレコードの役割を整理しておきます。 | レコード | 役割 | 今回の用途 | | --- | --- | --- | | **A** | ドメイン → IPv4アドレス | WordPressサーバーのIPを紐づける | | **AAAA** | ドメイン → IPv6アドレス | IPv6対応時に使用（なければ不要） | | **CNAME** | ドメイン → 別のドメイン名 | サブドメイン構成の場合に使用（今回は不使用） | | **MX** | メール配送先サーバーの指定 | 移管後に消えていないか必ず確認 | | **TXT** | 任意のテキスト情報 | SPF・DKIM・Search Console認証など | | **NS** | 権威DNSサーバーの指定 | Cloudflareへの移管時にレジストラ側で変更 | ## よくある質問 ### WordPress側の設定変更は必要ですか？ **不要です。**WordPressはこれまでどおり動き続けます。Cloudflare Workerがリクエストを受け取ってWordPressサーバーへ転送するだけなので、WordPress側からは通常のアクセスと同じに見えます。 ### Vercel側でドメインを追加する必要はありますか？ **必須ではありません。**WorkerからVercelの `*.vercel.app` のURLへ転送する構成のため、Vercel側のドメイン設定は変更せずに動作します。 ### Cloudflareの無料プランで足りますか？ 足ります。Workersの無料枠は1日10万リクエストまで利用でき、通常のコーポレートサイトやオウンドメディアであれば十分な範囲です。 ### Cloudflare Pagesを踏み台にする必要はありますか？ **不要です。**以前はWorkerにカスタムドメインを割り当てるためにPagesを経由する手法が紹介されることもありましたが、現在はWorkerのSettings → Domains & RoutesからCustom Domainを直接紐づけられます。 ### ダウンタイムは発生しますか？ ネームサーバーの切り替えは段階的に反映されるため、Aレコードなど既存のレコードが正しく移行できていれば、原則としてサイトが落ちることはありません。ただし**レコードの設定漏れがあるとその機能だけが停止します**（MXレコードならメール）。移管前のスクリーンショットが最大の保険になります。 ## まとめ Cloudflare Workerを使えば、**WordPressとVercelを1つのドメイン上でパス単位に共存させる構成が、無料枠かつ既存環境の変更なしで実現できます。**要点を振り返ります。 - パス単位の振り分けはDNSではできない。Cloudflare Workerの役割 - WorkerにはCustom Domainを直接紐づけられる（Pagesの踏み台は不要） - 最大のリスクはDNS移管時のMX・TXTレコードの消失。移管前のスクリーンショットが必須 - CSS崩れの原因はほぼ `/_next/` パスの振り分け漏れ サブパス構成は、既存サイトのドメイン評価を活かしたままモダンな技術スタックへ移行していくための、現実的な選択肢です。「WordPressは残したいが、新しいメディアは高速に作りたい」という状況であれば、まずこの構成を検討してみてください。 株式会社AI棒では、こうしたAI・Web技術の検証を日々行い、企業のAI活用と開発の内製化を支援しています。技術選定や構築についてのご相談は[お問い合わせフォーム](/contact)から、AI活用の伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIだけでiOSアプリを実機導入まで｜1日・0円で分かった本当の壁 - URL: https://ai-katsu.jp/articles/claude-code-ios-app - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-01T00:00:00+00:00 - Models: Claude Code - Tools: GitHub - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: 社内基盤・インフラ > AIコーディングツールだけで企画から実装、ビルド、実機のiPhoneへのインストールまでを1日で通しました。詰まったのはコードではなく環境——日本語パスでのビルド失敗、キーチェーンの署名拒否、Developer Mode。モバイル系プロジェクトは最初からASCIIパスで作るべき理由をまとめています。 外注の前に、まず動くものを自分の手元で作れないか。この検証は、その問いに対する答えです。 AIコーディングツールだけで、企画から実装、ビルド、そして**実機のiPhoneへのインストールまで**を1日で通しました。**費用は0円**です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年6月1日（1日で完了） | | やりたかったこと | AIコーディングだけで企画・設計・実装・ビルド・実機導入までどこまで通せるか検証する | | 技術スタック | Expo SDK 56 / React Native 0.85 / TypeScript / expo-sqlite / Xcode 26.5 | | 成果 | **単一ファイル（約1,600行）でMVPを実装し、実機へRelease版を単体インストール** | | 費用 | **0円**（無料Apple ID・ローカルビルド） | | 状況 | 完了（Phase 1 MVPの実機導入まで到達） | ## 結論：詰まるのはコードではなく環境 この検証で最も明確に分かったことです。 **環境差分（日本語パス・署名・Developer Mode）が主な壁で、コード自体より周辺がボトルネックでした。** 記録の中核ループ（開始 → 種目追加 → セット記録 → 完了 → 履歴）の実装は素直に通りました。SQLiteでの永続化、都度保存、履歴集計まで一気通貫です。 止まったのは、すべてネイティブアプリ特有の周辺工程でした。 ## 詰まりポイント①：日本語フォルダ名でビルドが失敗 最も時間を取られた問題です。 **日本語フォルダ名でiOSネイティブビルドが失敗しました。Appleのツールチェーンはマルチバイトパスに弱い**ためです。 技術的な原因も特定できています。**React Native 0.85のprebuilt artifactsはローカルパスを `file://` URIに変換するため、日本語が混ざると `bad component` で落ちます。** 対処は**フォルダ名の英語化（ASCII化）**でした。リポジトリを移設せず、パスだけをASCIIにすることで根治しています。 **教訓は明確です。モバイル系プロジェクトは最初からASCIIパスで作る。** 日本語のフォルダ名は日常的に使いますが、ネイティブビルドが絡む領域では避けるべき習慣になります。 ## 詰まりポイント②：署名がターミナルから通らない 次の壁は、コード署名です。 **ターミナルからの署名が `errSecInternalComponent` で失敗しました。**原因はキーチェーンの鍵アクセス権限です。 解決の手順が実用的です。 **Xcodeから一度Runして署名を「常に許可」しておくと、以降はターミナルからの署名も通過します。** つまり**実機の初回ビルドだけGUIで行い、その後はコマンドラインに戻る**という進め方です。全部をコマンドラインで完結させようとすると、ここで止まります。 ## 詰まりポイント③：Developer Modeとビルド種別 - **iOS 16以降は実機開発に端末側「デベロッパモード」が必須**（有効化して再起動が必要） - **dev buildはMac側のMetroが必要。**外出先での単体利用には**Release ビルド（JS内蔵）**が必要 2つ目は用途に直結します。**開発中の確認と、実際に持ち歩いて使うことでは、必要なビルドが違います。**この検証では実機常用のためRelease ビルドを採用しました。 あわせて、コマンドの落とし穴も記録されています。**引数が正しく渡らず、実機を指定したつもりがシミュレータで起動してしまう**ケースがありました。 ## 無料Apple IDの制約 コスト0円で実現できた一方、制約もあります。 **無料Apple IDではアプリが7日で期限切れになります。**切れたら同じコマンドで再インストールする運用です。 常用や配布には**Apple Developer Program（年99ドル）**が必要になります。 **「試す」目的なら0円で足ります。**継続利用や他人に配る段階で、初めて費用が発生する構造です。 ## PoCを内製化する価値 この検証の意義として整理されている点です。 **外注前のPoCを、追加費用ゼロで実機まで検証できました。**技術選定や要件の妥当性を、実物で確認できます。 企画書やモックで判断するのと、実際に自分のスマホで使ってみるのとでは、分かることが違います。**使ってみて初めて「この機能は要らない」「これが足りない」が見えます。** 実際、この検証でも仕様と実装の突き合わせレビューを行い、**フィードバックを受けて記録UXを改修**しています（一時保存・履歴の再編集・休憩時間のホイール選択）。 ## 技術選定の判断 実装上の判断も記録されています。 | 判断 | 理由 | | --- | --- | | CocoaPodsを採用 | メンテナンスモード入りだが、Expo SDK 56の `expo run:ios` が前提とするため | | リポジトリを移設せずフォルダ名だけ英語化 | マルチバイトパス問題の根治 | | **Release ビルドを採用** | **実機常用のため（Metro依存のdev buildでは外で使えない）** | 1つ目は現実的な判断です。**「将来的に非推奨」でも、現時点のツールチェーンが前提としているなら使うしかありません。**移行はツールチェーン側の課題として切り離しています。 ## 残っている課題 - Phase 1完了条件のうち2点が未達（前回実績の参照、種目別の推移グラフ） - **無料枠のため7日でアプリが失効する**（常用にはApple Developer Program + EAS Buildが必要） ## 横展開できること この検証で得られたのは、アプリそのものより**手順の型**です。 - **同じ手順で他のモバイルPoCを内製化できる**（環境構築・署名・実機導入の型ができた） - **受託前の「動く検証機」を提示する材料になりうる** **一度通した工程は、次からは詰まりません。**特に署名まわりは、最初の1回を越えられるかどうかが分かれ目になります。 ## よくある質問 ### AIだけでネイティブアプリを作れますか？ **実機導入まで到達できました。**ただしコード実装より、環境差分（日本語パス・署名・Developer Mode）のほうがボトルネックになります。 ### ビルドが失敗します **フォルダパスに日本語が含まれていないか確認してください。**Appleのツールチェーンはマルチバイトパスに弱く、prebuilt artifactsのURI変換で落ちます。モバイル系プロジェクトは最初からASCIIパスで作るのが確実です。 ### ターミナルから署名が通りません **Xcodeから一度Runして「常に許可」を選んでください。**以降はターミナルからの署名も通過します。初回だけGUIを使い、その後はコマンドラインに戻る進め方が現実的です。 ### 費用はかかりますか？ **自分用に試すだけなら0円です。**ただし無料Apple IDではアプリが7日で失効します。常用や配布にはApple Developer Program（年99ドル）が必要です。 ## まとめ - AIコーディングだけで**企画から実機導入まで1日で到達**（費用0円） - **詰まるのはコードではなく環境。**日本語パス・署名・Developer Modeが主な壁 - **モバイル系プロジェクトは最初からASCIIパスで作る** - 署名は**初回だけXcodeでRunして「常に許可」**すれば、以降はコマンドラインで通る - 持ち歩いて使うには**Release ビルド（JS内蔵）**が必要。dev buildはMac依存 - **無料Apple IDは7日で失効。**試す目的なら十分、常用には有料プログラムが必要 - 得られたのはアプリより**環境構築・署名・実機導入の型** 外注や本格開発の前に、動くものを手元で確かめられると判断の精度が上がります。実際に使ってみて初めて分かることは、企画書には書けません。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発内製化とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## GUI操作は最後の手段｜自動化レイヤの優先順位とトークン消費のメンタルモデル - URL: https://ai-katsu.jp/articles/computer-use-browser-use-local-llm-survey - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-06-01T00:00:00+00:00 - Models: Claude - Tools: Computer Use, Browser Use, MCP - Tasks: リサーチ・データ収集, 業務プロジェクト - Domain: 社内基盤・インフラ > AIエージェントの自動化レイヤをAPI → MCP → DOM操作 → CLI → GUI操作の階層で整理しました。「GUI操作回数 ≒ トークン消費量」というメンタルモデル、GUIエージェントが静止画を反復解析している事実、そしてBrowser Use 90% / CLI 5% / Computer Use 5%という目標比率をまとめています。 AIエージェントに作業を任せるとき、**「どの方法で操作させるか」の選択がコストと安定性を決めます。**GUI操作は万能に見えますが、最もコストが高く、最も壊れやすい方法でもあります。 この調査では、自動化レイヤの優先順位を階層として言語化し、**推奨する構成比率**まで整理しました。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査時期 | 2026年6月1日〜（検証中） | | やりたかったこと | 自動化レイヤ（API / MCP / DOM操作 / CLI / GUI）をどの順序で組み合わせるとコストと安定性のバランスが取れるかを整理する | | 結論 | **API → MCP → DOM操作 → CLI → GUI操作の階層。GUIは最後の手段** | | 目標比率 | **Browser Use 90% / CLI 5% / Computer Use 5%** | ## 結論：GUIは最後の手段 この調査で確立した優先順位です。 ``` API → MCP → DOM操作 → CLI → GUI操作 ``` 理由は明確です。**GUIは万能に見えますが、UI変更への耐性が低く、トークン消費も大きくなります。**そのため、GUIでしかできない処理に限定します。 使い分けの基準も具体的です。 | 対象 | 方式 | | --- | --- | | **DOMが存在する操作対象**（分析ツール、自動化SaaS、コード管理、チャットのWeb版等） | **Browser Use + Playwright + MCP** | | **DOMが存在しないネイティブアプリ**（エディタ、デザインツール、ファイラー、表計算のデスクトップ版等） | **Computer Use を許容** | **「DOMがあるか」が分岐点です。**あるならDOMを直接扱ったほうが速く、安く、安定します。 ## 「GUI操作回数 ≒ トークン消費量」 この調査で得た最も有用なメンタルモデルです。 Computer Useの高コスト要因は、**スクリーンショット取得 → LLM解析 → 次アクション決定というループを毎ステップ繰り返す構造そのもの**にあります。 そしてもう1つ、理解を助ける事実があります。 **GUIエージェントは画面を動画的に見ているのではなく、大量の静止画を反復解析しています。** 人間が画面を見る感覚とはまったく違います。**1回クリックするたびに、画面全体を読み直しています。**操作回数がそのままコストになる理由がここにあります。 対してBrowser Use系は、`document.querySelector()` や `button.click()` 相当でHTML構造を直接操作します。**高速かつ安定し、低コストです。** ## GUI操作を減らす3つの工夫 GUIを使わざるを得ない場合の対処です。 1. **事前に画面を準備する** — 対象のチャンネルやページを開いた状態で渡し、エージェントには操作だけを担当させる 2. **タスクを分割する** — 「確認 / 作成 / 修正」のように1ステップ完結のタスクへ分けてから渡す 3. **GUI探索を減らす** — フォルダを辿らせず、検索機能でファイル名を入力してEnterさせるなど、キーボードショートカットを優先する **3つとも「探させない」ための工夫です。**エージェントが画面上を探し回る時間が、そのままコストになります。 ## アーキテクチャの進化：構造化してから渡す 技術的に注目すべき動向です。 **従来の「画面全部を毎回LLMへ送る」運用から、UIを構造化し、小型モデルが実行、必要時のみ大型モデルへエスカレーションする構成への移行が進みつつあります。** これを支える技術が2つあります。 | 技術 | 役割 | | --- | --- | | **スクリーンショットのUI要素パーサー** | スクリーンショットからボタン・入力欄・アイコンといったUI要素を抽出し**構造化する前処理** | | **Planner / Executor / Grounding の分離** | **大型モデルが計画、小型モデルがクリック判定**を担う構成で、精度向上とコスト削減を両立 | **「見て判断する」を1つのモデルで全部やらせない**——役割を分けることで、それぞれに適したサイズのモデルを割り当てられます。 ## ローカルLLMという選択肢 コストを下げるもう1つの方向です。 GUI理解に強いローカルVLMとして、複数の選択肢が確認されています。GUI理解・テキスト認識・ボタン認識に強いモデルや、高解像度UI認識を重視したGUI専用寄りのモデルなどです。 ただし精度には差があります。 **ローカルLLMでもComputer Useは可能ですが、精度はクラウドの大型モデルに届きません。** そのため、**ローカル実行95% ＋ 高性能クラウドGUIエージェント5%**という構成比率も目安として挙げられています。 **難しい判断だけクラウドに投げる**という設計です。 ## GUIとCLIを組み合わせる 実運用に乗せやすい設計として評価されている考え方です。 **ファイル整理はスクリプト、変換処理はCLI、必要時のみGUI**——役割を切り分ける構成です。 同じ作業でも、**手段によってコストと安定性がまったく違います。**全部をGUIでやろうとする必要はありません。 ## 用途別の振り分け例 | 対象 | 方式 | | --- | --- | | コード管理サービス | Browser Use | | 分析ツール | MCP | | チャット通知 | **API** | | 開発サーバー起動 | **CLI** | | エディタでの編集 | Computer Use | **同じ「自動化」でも、対象ごとに最適な層が違います。**この振り分けを事前にルール化しておくと、都度悩まなくて済みます。 ## 長期タスクへの備え スケールしたときの課題も整理されています。 - **GUI操作中心の構成はUI変更に弱く、長期タスクで失敗率が上がる** - **スクリーンショット解析を繰り返すとトークン消費が線形以上に膨らむ** 対策として、**履歴圧縮・セマンティック要約・GUI構造化を組み合わせ、毎ターンの送信量を抑制する**方針が挙げられています。 **長く動かすほど、送信量の管理が効いてきます。**短いタスクでは問題にならない部分です。 ## 残っている検証課題 - ローカルLLMでのComputer Useの精度が、クラウド大型モデルにどこまで近づくか - **実際の運用比率（Browser Use 90% / CLI 5% / Computer Use 5%）が手元の業務でも成立するかの実測** ## よくある質問 ### なぜGUI操作を最後に置くのですか？ **UI変更への耐性が低く、トークン消費も大きいためです。**APIやDOM操作で済むなら、そちらのほうが速く、安く、安定します。 ### Computer Useのコストが高い理由は？ **スクリーンショット取得 → LLM解析 → 次アクション決定のループを毎ステップ繰り返す構造にあります。**GUIエージェントは動画的に画面を見ているのではなく、大量の静止画を反復解析しています。 ### GUIを使わざるを得ない場合は？ **事前に画面を準備する・タスクを分割する・キーボードショートカットを優先する**——この3点でGUI探索を減らせます。 ### ローカルLLMで代替できますか？ **可能ですが、精度はクラウドの大型モデルに届きません。**ローカル実行を主体にしつつ、難しい判断だけクラウドに投げる構成が現実的です。 ## まとめ - 自動化レイヤの優先順位は**API → MCP → DOM操作 → CLI → GUI操作**。GUIは最後の手段 - 分岐点は**「DOMが存在するか」。**あるならDOMを直接扱う - **「GUI操作回数 ≒ トークン消費量」**——GUIエージェントは静止画を反復解析している - GUI使用時は**事前に画面を準備・タスク分割・ショートカット優先**で探索を減らす - アーキテクチャは**UI構造化 → 小型モデルが実行 → 必要時のみ大型モデル**という方向へ進化 - ローカルLLMは可能だが**精度はクラウド大型モデルに届かない** - 目安は**Browser Use 90% / CLI 5% / Computer Use 5%** 自動化の設計では、何ができるかより「どの層でやるか」が結果を左右します。上位の層で済むことを下位の層でやると、コストも失敗率も上がります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 同じ組織のOSSでも採用可否は分かれる｜44リポを調べて分かった選定基準 - URL: https://ai-katsu.jp/articles/browser-use-ecosystem - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-28T00:00:00+00:00 - Tools: Browser Use, Cloudflare, MCP - Tasks: リサーチ・データ収集, 業務プロジェクト - Domain: 社内基盤・インフラ > ブラウザ自動化ツールを提供する組織の公開リポジトリを網羅調査しました。メンテ停滞・AGPLライセンス・PoC段階・特定OS専用など、READMEだけでは分からない差が出ています。Computer Use比でトークン消費が約1/8という選定軸と、エッジ環境ではブラウザバイナリが動かせないという制約もまとめています。 OSSのリポジトリが並んでいると、どれを使えばいいのか判断が難しくなります。名前が似ていて、機能も重なって見える。しかし調べていくと、**メンテナンスが止まっているもの、思想がまったく違うものが混ざっている**ことが分かります。 この検証では、ブラウザ自動化ツールを提供する組織の公開リポジトリを網羅調査し、**採用すべきもの・避けるべきもの**を切り分けました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月28日〜（検証中） | | やりたかったこと | Computer Useよりトークン効率と運用コストを下げられる代替を見つけ、無料枠クラウドにホストする価値があるか評価する | | 調査対象 | 公開**44リポ**のうち上位約13件を整理／うち**9リポを技術深掘り** | | 方法 | リサーチエージェント3並列で各リポの技術レポートを作成 | | 状況 | 調査完了・ローカル実機検証はこれから | ## 結論：同じ組織のリポでも採用可否は大きく分かれる 調査で判明した重要な事実を並べます。 | リポジトリ | 判明した事実 | 判断 | | --- | --- | --- | | ワークフロー系 | **v0.2.11（2024-11）止まりで事実上メンテ停滞中。かつAGPL-3.0** | **採用優先度を下げる** | | Web UI系 | **v3.0.0でブラウザ拡張へ大きく方向転換。**従来構成は実質レガシー | 方向性を確認して判断 | | 動画系 | **コミット16件でPoC段階** | **プロダクション投入は非推奨** | | **エージェントSDK** | **MIT・Playwright不要で256MB RAM動作可** | **無料枠クラウドとの相性が良い** | | **Cloud SDK** | **エッジ環境に直接デプロイ可能な唯一の選択肢**（ブラウザ不要のため） | 有力 | | VPS常駐型 | **特定OS専用・Docker非対応** | コンテナ構想とは思想が違う | **「同じ組織が出しているから、どれも同じ品質・同じ方針」ではありません。**ライセンス、更新頻度、前提とする実行環境がそれぞれ違います。 ## ライセンスは最初に確認する この調査で最も実務的な発見です。 **ワークフロー系のリポはAGPL v3.0のため、商用利用時のライセンス確認が必須**です。 AGPLは、ネットワーク経由でサービス提供する場合にもソース公開義務が生じ得るライセンスです。**「OSSだから自由に使える」という前提で組み込むと、後から問題になります。** 対照的に、エージェントSDKはMITライセンスです。**同じ組織のリポでもライセンスが異なる**——この確認を最初に行う価値があります。 ## トークン効率という選定軸 この検証の出発点は、Computer Useとの比較でした。 **ハーネス系のツールは、Computer Use比でトークン消費が約1/8**と報告されています。 Computer Useはスクリーンショットを画像トークンとして送るため、ステップ数が増えるほどコストが積み上がります。**CDP直結でDOM情報を扱う方式なら、この消費を大きく下げられます。** **「AIにブラウザを操作させる」という同じ目的でも、情報の渡し方でコストが1桁変わります。** ## ホスト先の選定：無料枠を軸に ホスト候補の選定にも判断基準があります。 | 候補 | 判断 | | --- | --- | | **エッジ実行系（Workers / Containers）** | **優先**——無料枠とエッジ実行の親和性を確認したい | | 各種クラウドの常時無料枠 | 候補 | | **一部のPaaS** | **除外**——無料枠の空きがない／制約がきつい | ここで**「ブラウザバイナリを同梱できるか」**が分岐点になります。 エッジ環境ではブラウザ本体を動かせないため、**ブラウザ不要の構成（Cloud SDK経由）でないと成立しません。**これが「エッジに直接デプロイ可能な唯一の選択肢」という評価につながっています。 ## MCPサーバーとして起動できる 実装上の要点です。 **メインのリポは `uvx --from 'browser-use[cli]' browser-use --mcp` でstdio MCPサーバーとして即起動できます。** AIエージェントから呼び出す前提の仕組みが、既に用意されているということです。 ただし課題も残っています。**stdio MCPをHTTP/SSEにラップするレイヤーの安定性が未確認**です。ローカルで動くことと、リモートから呼べることは別の問題になります。 ## ローカル検証を先行させる判断 進め方についての判断も記録されています。 **クラウドにホストする前に、各リポをローカルで触り、実機の手触り・トークン消費・ホスト難易度を確認してから判断する。** 調査だけで構成を決めると、動かしてみて初めて分かる制約に後から気づきます。**ホスト先を決める前に、そもそも動くものを選別しておく**という順番です。 検証は4波に分けて進める計画になっています。 1. **第1波（マスト）** — メインライブラリ / ハーネス / SDK 2. 第2波 — ワークフロー系 / エージェントSDK 3. 第3波 — 動画系 4. 第4波 — VPS常駐型 / デスクトップ / Web UI **優先順位をつけて、必須のものから確認します。**44リポを全部触ろうとすると終わりません。 ## 調査の進め方 この検証自体の作業方法も参考になります。 **リサーチエージェント3並列で9リポの技術深掘りを実施し、各サブディレクトリにレポートを配置**しました。 各レポートには、概要・アーキテクチャ・機能・インストール方法・LLM呼び出し経路・コンテナ適性・コスト・直近更新日・強弱・検証お題という項目が揃っています。 **調査項目を先に決めてから並列化すると、比較可能な形で結果が揃います。**項目がばらばらだと、集まっても比べられません。 ## この調査で得られる判断材料 OSSを選定するときに確認すべき項目として、この検証は良い例になっています。 - **直近の更新日**——メンテナンスが続いているか - **ライセンス**——商用利用に制約はないか - **コミット数・バージョン**——PoC段階か、実用段階か - **前提とする実行環境**——コンテナで動くか、特定OS専用か - **リソース要件**——無料枠に収まるか - **方向転換の有無**——メジャーバージョンで別物になっていないか **READMEを読むだけでは、このうち半分も分かりません。**更新履歴とライセンスファイルを見る必要があります。 ## よくある質問 ### 同じ組織のリポなら、どれを選んでも同じですか？ **違います。**メンテナンスが止まっているもの、PoC段階のもの、特定OS専用のもの、ライセンスが異なるものが混在しています。 ### Computer Useと比べてコストは下がりますか？ **ハーネス系はComputer Use比でトークン消費が約1/8**と報告されています。スクリーンショットではなくDOM情報を扱う方式のためです。 ### 無料枠のクラウドで動きますか？ **構成によります。**エッジ環境ではブラウザバイナリを動かせないため、ブラウザ不要の構成でないと成立しません。逆に、256MB RAMで動作しPlaywright不要のものは相性が良好です。 ### OSS選定で確認すべきことは？ **直近の更新日・ライセンス・コミット数・前提とする実行環境の4点は最低限確認してください。**READMEだけでは判断できません。 ## まとめ - 同じ組織のリポでも**メンテ状況・ライセンス・前提環境がそれぞれ違う** - **AGPL-3.0のリポは商用利用時にライセンス確認が必須。**MITのものと混在している - ハーネス系は**Computer Use比でトークン消費が約1/8。**情報の渡し方でコストが1桁変わる - エッジ環境では**ブラウザバイナリを動かせない。**ブラウザ不要の構成が必要になる - **ホスト先を決める前に、動くものを選別する** - OSS選定では**更新日・ライセンス・コミット数・実行環境**を最低限確認する - 並列調査は**項目を先に決めてから**実施すると比較可能な形で揃う OSSの選定は、機能比較より前に「まだ生きているか」「使ってよいか」の確認が必要です。ここを飛ばすと、動かしてから戻ることになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の技術選定とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 承認フローが仕様に組み込まれたComputer Use｜ブラウザ特化という設計判断 - URL: https://ai-katsu.jp/articles/google-project-mariner - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-27T00:00:00+00:00 - Models: Gemini - Tools: Computer Use, Google Cloud - Tasks: リサーチ・データ収集, ツール検証 > GoogleのComputer Useを3社比較の一環で調査しました。対象をブラウザとAndroidに絞る代わりに入力料金は3社中最安。safety_decisionによる承認フローが仕様に組み込まれ、確認の自動バイパスはToSで明示的に禁止されています。安全運用の3点セットもまとめています。 AIにブラウザを操作させるとき、最も怖いのは**「勝手に何かを実行してしまうこと」**です。購入ボタンを押す、規約に同意する、送信してしまう——取り返しがつかない操作は避けたい。 Google のComputer Useは、この点に**明示的な承認フロー**を組み込んでいます。この検証では、3社比較の一環としてその設計を調査しました。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査時期 | 2026年5月27日〜28日 | | 対象 | Google Gemini Computer Use（Gemini Developer API / Vertex AI） | | 対応範囲 | **ブラウザ＋Android UI** | | コスト | **入力 $1.25〜2.50 / 出力 $10〜15（per 1M）**——3社中最も安価 | | 提供状況 | **Preview**（GAなし） | > 本記事は一次情報（公式ドキュメント）に基づく調査記録です。実機での精度・レイテンシ計測は未実施のため、実測値は含みません。 ## 結論：ブラウザ完結の業務に絞るのが筋 3社を比較したうえでの位置づけです。 **Googleは主にブラウザ前提（`ENVIRONMENT_BROWSER`）でデスクトップ操作は公式想定外のため、ブラウザ完結業務に絞るのが筋。** これは弱点ではなく、**設計思想の違い**と読むべきです。対象を絞ることで、その範囲での最適化が効きます。 実際、コスト面では明確に優位です。 | ベンダー | 入力（per 1M） | 出力（per 1M） | | --- | --- | --- | | **Google** | **$1.25〜2.50** | **$10〜15** | | OpenAI | $2.50 | $15 | | Anthropic | $5 | $25 | 1サイトあたりのコスト試算でも、**コンテキストキャッシュ併用で約$0.05〜0.07と3社中最安**という結果でした。 ## `safety_decision`：承認フローが仕様に組み込まれている この実装で最も注目すべき点です。 **`safety_decision` フィールドをアプリケーション側で必ず処理する**——という設計になっています。 さらに規約レベルでの制約もあります。 **ToSで `require_confirmation` の自動バイパスを明示的に禁止しています。** つまり**「確認をスキップする実装」自体が規約違反**です。技術的に回避できても、やってはいけない。 禁止ユースケースも明示されています。 - **CAPTCHA解析** - **ユーザー同意なしの法的条件承認** - **明示的承認なしの金融取引** **「AIが人の代わりに同意する」ことへの線引きが、仕様と規約の両方で引かれています。**自動化を設計する側にとって、この境界は明確なほうが判断しやすくなります。 ## 安全に動かすための3点 公式が示す運用上の推奨事項です。 1. **`safety_decision` フィールドをアプリケーション側で必ず処理する** 2. **サンドボックスVM / コンテナでの実行を前提とする** 3. **ナビゲーション許可リスト / ブロックリストをカスタムシステムプロンプトに含める** 3つ目が実用的です。**どのサイトに行ってよいかを事前に指定しておけば、意図しないページへの遷移を減らせます。**プロンプトインジェクションへの備えにもなります。 ## 優位性 - **クラウド統合により既存環境にスムーズに組み込める** - **入力料金が3社中最も安価** - **Android UI対応**——モバイルアプリの操作という他社にない領域 - **`safety_decision` による明示的な承認フロー設計** - Webタスクのベンチマークで70%+の性能を公式が主張 Android対応は独自性があります。**ブラウザで完結しないモバイル業務が対象になり得ます。** ## 懸念点 - **全体的にPreview扱いでGAなし** - **公式が「エラーと脆弱性が生じやすい可能性」と注意喚起している** - ベンチマークの具体数値が公式ブログの画像内にあり、数値として抽出できない - **無料枠なし** - 関連する実験的プロダクトは特定地域の上位プラン限定で、日本からUI経由では利用できない - 同時実行・タイムアウト等の定量制約が公式に不明 2つ目は重要です。**提供元自身が不安定さを明示しています。**これを前提に、失敗しても影響が小さい範囲から始めるべきです。 ## 座標系の扱い 実装上の特徴として、**1000×1000グリッドの座標を実画面解像度にスケーリングする**方式をとっています。 画面サイズが変わっても指示側の座標系は一定になるため、**解像度依存の実装を避けられます。** あわせて、カスタム関数によるアクション拡張にも対応しています。 ## ベンダーロックインの観点 導入判断時の留意点として整理されています。 **クラウドプラットフォームへの統合が深い場合、移行コストは高めになります。** 統合の深さは、導入の容易さと引き換えです。**既にそのクラウドを使っているなら利点、そうでないなら検討事項**になります。 ## よくある質問 ### デスクトップアプリは操作できますか？ **公式想定外です。**主にブラウザを対象としており、Android UIにも対応しています。デスクトップ操作が必要な場合は他社の選択肢を検討することになります。 ### 確認フローをスキップできますか？ **できません。**ToSで確認要求の自動バイパスが明示的に禁止されています。CAPTCHA解析、同意なしの法的条件承認、承認なしの金融取引も禁止ユースケースです。 ### コストは安いですか？ **3社中最も安価です。**入力$1.25〜2.50 / 出力$10〜15（per 1M）で、1サイトあたりの試算でもキャッシュ併用で約$0.05〜0.07と最安でした。ただし無料枠はありません。 ### 本番運用できますか？ **Preview扱いのため慎重な判断が必要です。**公式自身が「エラーと脆弱性が生じやすい可能性」と注意喚起しています。 ## まとめ - Googleの Computer Use は**ブラウザ＋Android が対象。**デスクトップ操作は公式想定外 - **入力料金が3社中最安**（1サイト約$0.05〜0.07） - **`safety_decision` による承認フローが仕様に組み込まれている**。自動バイパスはToS違反 - CAPTCHA解析・同意なしの法的条件承認・承認なしの金融取引は**禁止ユースケース** - 安全運用の要点は**承認処理・サンドボックス実行・ナビゲーション許可リスト**の3点 - **Preview扱いでGAなし。**公式自身が不安定さを注意喚起している - Android UI対応は**他社にない領域** AIに操作を任せるとき、「どこで止まるか」の設計が安全性を決めます。仕様として承認フローが組み込まれているかどうかは、選定時の判断材料になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 「デスクトップ操作」の実態はLinux操作｜Computer Useが日本企業で完結しない理由 - URL: https://ai-katsu.jp/articles/anthropic-computer-use - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-27T00:00:00+00:00 - Models: Claude, AWS Bedrock - Tools: Computer Use - Tasks: リサーチ・データ収集, ツール検証 > Computer Useの3社横断調査です。各社が言う「デスクトップ対応」は実質Linuxデスクトップを指し、日本企業に多いWindowsネイティブの業務アプリを操作するには別レイヤーが必要になります。Playwrightとの使い分け、1サイト$0.05〜0.40というコスト感、導入の段階的アプローチをまとめています。 Computer Useの説明には「デスクトップ操作に対応」と書かれています。しかし調べていくと、**その「デスクトップ」が何を指すのか**が、日本企業の業務適用では決定的に重要になります。 この検証では、Anthropic Computer Useを軸に3社を横断調査しました。最も重要な発見は**「Computer Useのデスクトップ操作＝実質Linuxデスクトップ操作」**という事実です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月27日〜（検証中） | | 対象 | Anthropic Claude Computer Use（`computer_use` tool）／ツールバージョン `computer_20251124` | | やりたかったこと | 「ブラウザ・GUIをAIに操作させる」ユースケースの実現可能性とコストを定量化する | | 提供形態 | API経由 / Amazon Bedrock / Google Cloud Vertex AI | | 状況 | **Public Beta継続中**（2024年10月公開以降） | > 本記事は一次情報（公式ドキュメント）に基づく調査記録です。実機での成功率・レイテンシ計測は継続中のため、実測値は含みません。 ## 結論：デスクトップ操作＝Linuxデスクトップ操作 各社が「デスクトップ操作対応」と説明する場合、実態はこうです。 **Linuxカーネル系OS（Ubuntu / Debian / CentOS等）の上で動くデスクトップ環境を操作する、という意味になります。**公式デモもUbuntu + Xfce + Firefoxの構成です。 ここが日本企業にとって最大の制約になります。 **日本企業の業務アプリはWindowsネイティブが多い**——会計ソフト、業務パッケージ、Officeデスクトップ版、設計ソフト等です。これらをComputer Useで操作したい場合、**別途VM + RDP/VNC接続のレイヤーが必要**になります。 ### Windows環境へのアクセス方式 | 方式 | コスト | 運用 | 適性 | | --- | --- | --- | --- | | クラウドWindows VM + RDP | 月$30〜150 | ネットワーク制御・踏み台・MFA設定が必要で重い | 企業導入 | | **マネージドのクラウドWindows** | $24〜162/月/ユーザー | **ID連携が標準** | **企業導入（最もクリーン）** | | コンテナ内でWindows VM | ライセンス持ち込み | 自己責任 | 個人検証・社内PoC | | AI専用デスクトップサンドボックス | 秒課金 | ベンダー側で隔離・監査 | スポット利用 | macOSはさらに厳しく、**クラウドのMacインスタンス（約$1.083/時、24時間の最小コミット）が唯一の現実的選択肢**です。よほどの理由がない限り避けるべき領域という判断になっています。 この検証では、**コスト・運用負荷がリターンに見合わないと判断し、Windows環境への実機検証は実施していません。** ## Playwrightの代替ではなく、補完 もう1つの重要な整理です。 **Computer Useの出番は「Playwright代替」ではなく「Playwrightが苦手な領域の補完」です。** 公開Webサイトからの情報取得は、Playwrightが圧勝します。**コストが1桁以上違います。** | | コスト（1サイト10ステップ） | | --- | --- | | Playwright | **ほぼ$0** | | Computer Use（各社） | **$0.05〜0.40程度**（モデル・キャッシュ有無で大きく変動） | ではComputer Useが光るのはどこか。次の6つです。 1. **ログイン後の業務SaaS操作** 2. **DOM変化が激しい新興ツール** 3. **画像・図表ベースの抽出** 4. **クロスアプリのワークフロー** 5. **長尾の一回限りタスク** 6. **強いBot対策のあるサイト** **「毎日同じサイトから同じデータを取る」ならPlaywright。「今回だけ、この複雑な操作をやりたい」ならComputer Use**——という使い分けです。 ## Anthropic Computer Useの特徴 ### 優位性 - **視覚認識精度**（第三者評価で98.5%との報告） - **OSWorldベンチで66.26%**と高水準 - **VM / コンテナでの隔離運用が公式ガイドラインで明確** - **大型画像入力（長辺2,576px）に対応** - 新ツールバージョンで `zoom`（領域拡大）が追加 ### 懸念点 - **通常のチャットUIでは利用できず、エンドユーザー向けの面が存在しない**（API専用） - Beta継続中で破壊的変更のリスクがある - 同時実行・タイムアウト等の定量制約が公式に明示されていない - **デスクトップ操作の対象が実質Linuxに限られる** ## 3社の位置づけ | 項目 | Anthropic | OpenAI | Google | | --- | --- | --- | --- | | 機能範囲 | デスクトップ全般 / `zoom` | チャットUI＋API＋デスクトップアプリ | ブラウザ＋Android | | コスト（入/出 per 1M） | $5 / $25 | $2.50 / $15 | **$1.25〜2.50 / $10〜15** | | 使いやすさ | コンテナデモが成熟 | **ノーコードで使える面がある** | クラウド統合 | | 提供状況 | Public Beta | **一部GA** | Preview | **3社とも一長一短で、どれか1つが優れているという状況ではありません。**コストならGoogle、エンドユーザー向けの完成度ならOpenAI、隔離運用のガイドラインとデスクトップ範囲ならAnthropic——という整理になります。 ## コストの実感 数十サイトを横断するニュース収集システムのコスト試算も行っています。 - 中位モデル + プロンプトキャッシュで**1サイトあたり約$0.08〜0.10** - 上位モデルは新トークナイザの影響で**+35%程度**とさらに高くなる また、Beta機能を使うことによるオーバーヘッドもあります。**システムプロンプトに466〜499トークンが加算されます。** **スクリーンショットは画像トークンとして課金されるため、`zoom` 機能でリージョン限定取得を活用する**ことがコスト削減につながります。 ## 業務適用の段階的アプローチ 実務での導入順序も整理されています。 | フェーズ | 対象 | 必要な準備 | | --- | --- | --- | | **Phase 1** | **Web SaaS業務**（営業のCRM、マーケの分析ツール、CSのチケット起票） | **現状のコンテナそのままで動く** | | Phase 2 | Linuxネイティブアプリ業務（チャットツール・ドキュメント・会議ツール等） | Dockerfileの拡張 | | Phase 3 | **Windows専用業務** | **クラウドWindows環境の追加（コスト・運用負荷が一気に上がる）** | **Phase 1から始めれば、追加の環境構築なしで効果を確認できます。**いきなりWindows業務を対象にすると、環境構築だけで止まります。 ## 実行時の推奨事項 - **隔離環境（VM / Docker）で動作させる** - **推奨解像度1024×768から開始する** - 機密データを含むセッションは扱わない - Windows/Mac接続を検討する場合は、シークレット管理・監査ログ・ネットワーク分離の設計が別途必要 ## よくある質問 ### WindowsのソフトをAIに操作させられますか？ **Computer Use単体ではできません。**各社のデスクトップ操作は実質的にLinuxデスクトップが対象です。Windowsアプリを操作するには、クラウドWindows環境を用意してRDP等で接続するレイヤーが必要になります。 ### Playwrightとどちらを使うべきですか？ **公開Webサイトの定型的な取得ならPlaywrightです。**コストが1桁以上違います。Computer Useが効くのは、ログイン後のSaaS操作、DOM変化が激しいツール、画像ベースの抽出、クロスアプリの作業などです。 ### コストはどのくらいですか？ **1サイト10ステップの実行で$0.05〜0.40程度です。**モデルとキャッシュの有無で大きく変動します。スクリーンショットが画像トークンとして課金されるため、取得範囲を絞ることがコスト削減につながります。 ### どこから始めるべきですか？ **Web SaaS業務からです。**コンテナ環境そのままで動くため、追加の環境構築なしで効果を検証できます。 ## まとめ - **Computer Useのデスクトップ操作＝実質Linuxデスクトップ操作。**Windows/Macアプリは別レイヤーが必要 - 日本企業の業務アプリはWindowsネイティブが多く、**これがComputer Use単独で完結しない最大の制約** - **Playwright代替ではなく補完。**公開Webの定型取得はPlaywrightが1桁以上安い - Computer Useが光るのは**ログイン後のSaaS操作・DOM変化の激しいツール・画像ベース抽出・クロスアプリ作業** - コストは**1サイト10ステップで$0.05〜0.40**。スクリーンショットの取得範囲がコストに直結する - 導入は**Web SaaS業務から始める。**Windows業務は最後 - 3社とも一長一短。**コスト・完成度・対応範囲で選ぶ軸が変わる** 新しい技術の適用範囲は、説明文だけでは分かりません。「デスクトップ対応」が何を指すのかを確認するだけで、実現可能性の見積もりが変わります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 「見出しを3つ読み上げて」で失敗する｜Computer Useは指示設計で結果が変わる - URL: https://ai-katsu.jp/articles/openai-operator-cua - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-27T00:00:00+00:00 - Models: OpenAI API, OpenAI Codex - Tools: Computer Use - Tasks: リサーチ・データ収集, ツール検証 > OpenAIのComputer Useを実機で動かしました。スクリーンショット取得からクリック・タイピングまで基本動作は安定した一方、素朴なニュース取得タスクは16ステップで打ち切り。原因は指示の曖昧さでした。3系統の提供形態、VNCによるデバッグ、廃止予定モデルへの注意もまとめています。 「Yahooニュースのトップ見出しを3つ読み上げて」——この程度のタスクなら簡単に見えます。しかし実際に実行したところ、**16ステップで打ち切りとなり、見出しの抽出に到達しませんでした。** この検証では、OpenAIのComputer Useを実機で動かし、**初手の指示設計がどれだけ結果を左右するか**を確認しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月27日〜28日 | | 対象 | OpenAI Computer Use（3系統の提供形態） | | 実行環境 | Dockerコンテナ + VNC可視化 | | 結果 | **ループ機構は安定動作。ただし初回タスクは失敗** | | 提供状況 | **チャットUI版はGA**（3社中唯一） | ## 結論：動くことと、意図どおり動くことは別 実機で確認できたことを、順に整理します。 **ステップ実行・スクリーンショット取得・座標クリック・タイピング・スクロール・ドラッグはすべて基本動作しました。**ループ機構（screenshot → action → screenshot の往復）も安定しています。 つまり**仕組みとしては問題なく動いています。**それでもタスクは失敗しました。 ### 失敗の原因 1. **デフォルトの開始URLが検索エンジンで、検索ステップから始まる必要があった** 2. **検索語を誤訳し、結果ページで迷子になった** 3. **「読み上げて」という指示が画面操作系モデルには曖昧で、要約・抽出のどちらをすべきか判断できなかった疑い** 3つ目が本質的です。**人間には自然な言い回しでも、操作を実行するモデルにとっては何をすべきか特定できません。**「読み上げる」は音声出力なのか、テキスト抽出なのか、要約なのか。 **対策は明確です。URLを直接指定し、タスク指示を抽出系の語彙で書けば実用範囲に乗る**という感触が得られています。 **ニュース系の素朴な見出し取得タスクでさえ、初手の指示設計が結果を大きく左右します。** ## デバッグにはVNC可視化が効く 実行環境の構成で有効だった点です。 **VNC経由でブラウザ操作の様子をリアルタイムに可視化でき、デバッグが容易でした。** 「なぜ失敗したか」は、ログだけでは分かりません。**実際にどこをクリックし、どのページに迷い込んだかを目で見られると、原因の特定が速くなります。** 接続時の注意点も記録されています。**生のVNCプロトコル用ポートはブラウザでは開けません。**ブラウザから見る場合はnoVNC用のポートを使う必要があります。 ## 3系統の提供形態 OpenAIは他社と異なり、複数の入り口を用意しています。 | 形態 | 内容 | 対象 | | --- | --- | --- | | **チャットUI上のエージェント** | ビジュアル/テキストブラウザ・ターミナル・API | **エンドユーザー（ノーコード）** | | **API の `computer` ツール** | 開発者がVM等を用意し、スクリーンショット→アクションのループを実装 | 開発者 | | **デスクトップアプリ（macOS）** | macOS GUIを操作 | 開発者・パワーユーザー | **コンシューマ向けの面が唯一GAに到達している**点が、3社比較での明確な優位性です。 他社はAPI経由が前提で、エンドユーザーがそのまま使える形にはなっていません。 ## サンドボックス連携がSDKにネイティブ実装 開発者向けの特徴です。 **Agents SDKが外部サンドボックスをネイティブサポートしています**（2026年4月の更新）。複数のサンドボックスサービスに対応しています。 Computer Useを安全に動かすには隔離環境が必須ですが、**その環境の用意がSDK側で用意されているかどうかは、実装コストに直結します。** ## 安全設計：確認要求のリコール率 公式が示している数値です。 **High-risk actionのゲーティングにおいて、確認要求のリコール率は92%**とされています。 つまり**危険な操作の92%は確認を求める**ということです。裏を返せば、**8%は確認なしで通る可能性がある**とも読めます。 **「確認フローがあるから安全」ではなく、「確認フローがあっても隔離環境で動かす」という設計が必要です。** ## 料金と利用制限 | 項目 | 内容 | | --- | --- | | モデル料金 | $2.50〜$5.00 / 入力1M、$15.00〜$30.00 / 出力1M（モデルによる） | | 専用モデル | 入力 $3.00 / 出力 $12.00 per 1M | | **チャットUI版のメッセージ数** | **上位プランで月400、その他有料プランで月40** | メッセージ数の制限は無視できません。**月40メッセージでは、業務での継続利用は難しい水準です。**本格的に使うならAPI経由になります。 ## 懸念点 - **専用モデルが2026年7月23日に廃止予定で、移行が必要** - 同時実行・タイムアウト・per-tool-call料金の具体数値が公式に不明 - **デスクトップアプリのComputer Useは一部地域が対象外**（EEA / UK / スイス除外、macOS限定） 1つ目は導入判断に直結します。**廃止予定のモデルを前提に実装すると、移行作業が確定します。**新規で始めるなら、後継の構成を選ぶべきです。 ## 3社の中での位置づけ | 項目 | OpenAI | Anthropic | Google | | --- | --- | --- | --- | | 機能範囲 | **チャットUI＋API＋デスクトップで広域** | デスクトップ全般 | ブラウザ＋Android | | コスト（入/出 per 1M） | $2.50 / $15 | $5 / $25 | **$1.25〜2.50 / $10〜15** | | 使いやすさ | **ノーコードで使える面がある** | コンテナデモ前提 | クラウド統合 | | 提供状況 | **チャットUI版はGA** | Public Beta | Preview | **OpenAIの強みは「入り口の広さ」です。**エンドユーザーから開発者まで、それぞれに合った形が用意されています。 ## よくある質問 ### 簡単なタスクなら確実に動きますか？ **動くとは限りません。**「ニュースの見出しを3つ読み上げて」という素朴なタスクでも、16ステップで打ち切りとなりました。URLを直接指定し、抽出系の語彙で指示することが必要です。 ### 失敗の原因はどう調べますか？ **VNC経由で操作の様子をリアルタイム可視化すると特定が速くなります。**ログだけでは、どこをクリックしてどう迷ったかが分かりません。 ### ノーコードで使えますか？ **チャットUI上のエージェントが使えます**（3社中唯一GA）。ただしメッセージ数に制限があり、上位プランで月400、その他有料プランで月40です。 ### これから実装する場合の注意点は？ **専用モデルが2026年7月23日に廃止予定です。**これを前提に実装すると移行作業が確定するため、後継の構成を選ぶべきです。 ## まとめ - **仕組みが動くことと、意図どおり動くことは別。**ループ機構は安定していたが初回タスクは失敗した - 失敗の主因は**指示の曖昧さ**。「読み上げて」は操作系モデルには特定できない - 対策は**URLを直接指定し、抽出系の語彙で書く** - **VNCによる可視化がデバッグを大きく助ける** - 3系統の提供形態を持ち、**コンシューマ向けの面が唯一GA** - 確認要求のリコール率は92%。**確認フローがあっても隔離環境は必要** - **専用モデルは2026年7月23日に廃止予定。**新規実装では後継構成を選ぶ AIに操作を任せるとき、うまくいかない原因はモデルの能力より指示の曖昧さにあることが多くあります。人間相手なら通じる言い方が、そのまま通じるとは限りません。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIが危険なコードを書く前に止める｜PreToolUseフックの実力と2つの落とし穴 - URL: https://ai-katsu.jp/articles/security-guidance-hook - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-27T00:00:00+00:00 - Models: Claude Code - Tools: GitHub - Tasks: 開発・エンジニアリング, ツール検証 > AI駆動開発では事後レビューが間に合わない、という課題に対し、コードが書かれる直前にパターン警告を出すフックを検証しました。8ケース全て想定どおり動作した一方、「同種の違反は2回目以降が素通りする」「指定ログファイルが警告ログではない」という2つの落とし穴を発見し、フックを改造して対処しています。 AIがコードを書く速度に、人間のセキュリティレビューは追いつきません。**「書かれた後に人が確認する」モデルでは間に合わない**——これがAI駆動開発の構造的な課題です。 この検証では、**コードが書かれる直前にパターン警告を出すフック**を導入し、実際にどう動くかを8ケースで確認しました。**そして分かった仕様の落とし穴に対処するため、フック自体を改造しています。** ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月27日〜（進行中） | | 対象 | Claude Code 公式プラグイン（`PreToolUse` フック方式） | | 仕組み | Edit/Write/MultiEdit の**直前**にパターンマッチで警告 | | 実体 | Pythonスクリプト 約280行／正規表現・キーワードベースの検出 | | 結果 | **8ケース全て想定どおり動作。ただし2つの仕様上の落とし穴を発見** | ## 結論：三層防御のうち、実装中の層が埋まった この検証の狙いは、既存の防御体制に欠けていた層を埋めることです。 | 層 | 導入前 | 導入後 | | --- | --- | --- | | **リアルタイム警告（実装中）** | **なし** | **フックで検知** | | オンデマンド監査 | セキュリティ監査エージェント | そのまま温存 | | CIゲート | ワークフロー | そのまま温存 | **「リアルタイム × オンデマンド × CI」の三層防御**という構成です。それぞれ検知できるタイミングと粒度が違います。 ## ブロックの仕組み 動作確認で判明した実装仕様です。 **ブロック方式はexit code 2 + stderr出力。**Claude Codeがstderrを「ガイダンス」として読み、ツール実行を中断する設計になっています。 検証した8ケースの結果は次のとおりです。 | # | ケース | 結果 | | --- | --- | --- | | 1 | 安全なコンテンツ | 素通り ✅ | | 2〜5 | 危険な関数呼び出し・XSS系パターン | ブロック ✅ | | 6 | **CIワークフローファイルへの書き込み** | **ブロック ✅**（パスベース検出） | | 7 | ケース2と同条件で再実行 | **素通り**（重複抑制） | | 8 | 対象外ツール | 素通り ✅ | ケース6が興味深い挙動です。**ファイルパスベースの検出が機能し、CIワークフローの配置先では内容に依らず警告が出ます。**「このディレクトリに書くこと自体がリスク」という判断です。 ## 落とし穴①：2回目以降が静かに通る ケース7で判明した仕様です。 **警告はセッション内・ファイル内・ルール内で1回だけ表示されます。**同じ警告を連続して見せないUX配慮ですが、裏を返すと問題になります。 **連続編集中は、2回目以降の同種違反が素通りします。** AIが同じパターンのコードを複数箇所に書いた場合、最初の1箇所しか警告されません。**「警告が出ていない＝安全」ではない**という状態になります。 ## 落とし穴②：ログファイルが警告ログではない もう1つの発見です。 **出力先として指定されているログファイルは、警告ログではありませんでした。**ログ書き込み関数はJSONパース失敗時にしか呼ばれない実装で、通常運用ではファイルが作られません。 **警告履歴を残したいなら、フック側にログ出力を1行追加するカスタマイズが必要です。** ファイル名から役割を推測すると、誤った理解のまま運用することになります。**実装を読んで確認する価値がある部分でした。** ## 改造：監査ログを残す 2つの落とし穴への対処として、フックスクリプトを改造しました。 ### 設計判断 - **記録するのはメタ情報1行のみ**（警告本文ではなく セッション / ツール / ファイル / ルール）——grepしやすく、肥大化しない - **重複抑制のチェックより前にログ書き込み**——stderr警告は抑制されてもファイルには全件残る - **書き込み失敗は握りつぶす**——ログ周りのトラブルで開発を止めない - **一時ディレクトリではなくプロジェクト同梱**——チームに配布したとき、clone直後から監査証跡が同じ場所に出る 2つ目が本質的な対処です。**「画面では1回・ログには全件」の二段運用**にすることで、UX配慮を保ちながら見落としを防げます。 ログの出力先は `.gitignore` 済みのため、リポジトリは汚れません。 ## 誤検知：この検証ログ自体がブロックされた 実運用上の重要な注意点です。 **この検証ログ自体が、フックに2回ブロックされました。** 原因は明確です。**危険なAPIの「解説目的の文字列」にもパターンマッチが反応するため**です。セキュリティについて文章を書こうとすると、危険な関数名を書くことになります。 対処は**ドキュメント用途では識別子をバッククォート等で分断する**ことです。 **パターンマッチによる検知は、コードと文章を区別できません。**ドキュメントやテストフィクスチャ内の文字列にも反応する前提で運用する必要があります。 ## 責務分担を明確にする この検証で整理された役割分担です。 | 仕組み | 担当する範囲 | | --- | --- | | **フック** | 即時のパターン検知（Edit/Write/MultiEditのみ） | | **セキュリティ監査エージェント** | 構造的な監査 | | **設定ファイルの deny ルール** | **危険なコマンドのガード** | 3つ目が重要です。**フックの対象はファイル編集系ツールのみで、コマンド実行系はカバーしません。**そちらは別の仕組みで止める必要があります。 **1つの仕組みで全部を防ごうとすると、穴に気づけません。**何がどこまでを担当するのかを明文化しておくことが重要です。 ## 配布性：cloneするだけで同じガードが効く この構成のもう1つの利点です。 フックスクリプトをプロジェクトに同梱し、設定から参照する形にしました。**チームメンバーがcloneするだけで、同じガードレールが効きます。** 個人環境にインストールする方式だと、**「誰がどの設定を入れているか」がばらつきます。**プロジェクトに含めれば、全員が同じ基準になります。 ## 残っている検証項目 - パターン拡張（日本語コメントの禁止表現、チェックリスト準拠） - 実セッションでのフック表示確認 - フック実行による編集の体感的な遅延（レイテンシ） - 誤検知率の定量評価 ## よくある質問 ### なぜ事後レビューでは足りないのですか？ **AIがコードを生成する速度に、人間のレビューが追いつかないためです。**実装中に検知できれば、危険なコードが書かれた時点で止められます。 ### 警告が出なければ安全ですか？ **そうとは限りません。**警告はセッション内・ファイル内・ルール内で1回だけ表示される仕様のため、連続編集中は2回目以降の同種違反が素通りします。ログを全件記録する改造で対処できます。 ### ドキュメントを書くときに邪魔になりませんか？ **実際にブロックされます。**危険なAPIの解説文字列にもパターンマッチが反応するためです。識別子をバッククォート等で分断する対処が必要です。 ### これだけで十分ですか？ **不十分です。**フックの対象はファイル編集系ツールのみで、コマンド実行系はカバーしません。オンデマンド監査とCIゲートを含めた三層で構成する必要があります。 ## まとめ - AI駆動開発では**事後レビューが間に合わない。**実装中の検知層が必要 - ブロックは**exit code 2 + stderr出力**で実現されている - **警告はセッション・ファイル・ルールごとに1回だけ。**2回目以降の同種違反は素通りする - 指定されたログファイルは**警告ログではなくエラーログ専用**だった。実装を読んで確認する価値がある - 対処は**「画面では1回・ログには全件」の二段運用** - **解説目的の文字列にも反応する。**ドキュメント執筆時は識別子を分断する - **フック・監査エージェント・denyルールの責務分担**を明文化する。1つで全部は防げない - プロジェクト同梱にすると**cloneするだけで全員に同じガードが効く** ガードレールは、入れただけでは機能しません。どこまで検知し、どこを見逃すのかを実際に試して確認すると、必要な補強が見えてきます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 中継を外してLINE×GAS直結にする｜スプレッドシートだけで回すRAGの実装記録 - URL: https://ai-katsu.jp/articles/line-gas-spreadsheet-rag - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-20T00:00:00+00:00 - Models: OpenAI API - Tools: LINE, Google Apps Script, Google Workspace - Tasks: ナレッジ活用・RAG, 業務プロジェクト - Domain: マーケティング > ワークフローツールの中継を廃し、LINE Webhookをスプレッドシート連携のスクリプトで直接受ける構成に変更しました。hashによる差分検知で再ベクトル化コストをほぼゼロに、類似度閾値とLLM判定の二重フィルタで「返さない」判断を実装。実行環境の制約で署名検証ができない点と、その移行経路もまとめています。 前回の設計では、ワークフローツールを中継してLINEとスプレッドシートをつないでいました。しかし**ユーザーがWebの回答画面へ誘導され、通常のLINEチャット体験から外れる**という問題がありました。 この検証では中継を廃し、**LINE Webhook → GAS 直結**の構成に変更。実機でのE2E疎通まで確認しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月18日〜5月20日（実機E2E疎通まで） | | 構成 | LINE Messaging API + GAS Web App（`doPost`）+ スプレッドシート + OpenAI（Embeddings / Chat Completions） | | やりたかったこと | 中継を挟まずに三段構え判定を成立させ、運用者がスプレッドシートだけで完結できるFAQ更新フローを確立する | | 応答時間 | **埋め込み 約0.3秒 + LLM判定 約1〜3秒**（replyToken有効時間内に余裕で完結） | | ナレッジ件数 | 約20数件（FAQ初期投入分） | | 状況 | 実機動作確認済み・**回答精度の本格評価は未完了** | ## 結論：構成要素を減らすと運用が回る 中継を外した効果は明確でした。 **構成要素が「LINE / GAS / スプレッドシート / OpenAI」だけに収まり、障害点・運用窓口がシンプルになりました。** 運用者から見た変化はさらに大きくなります。**管理画面を一切触らず、スプレッドシートのみで完結できる体験**になりました。 中継ツールを入れる判断は、機能面では合理的でも**運用窓口を1つ増やします。**誰がどこを触るのかが分かれると、更新が止まります。 ## スプレッドシートの設計 | 列 | 内容 | 編集者 | | --- | --- | --- | | A | ID | **運用者が編集** | | B | 質問 | | C | 回答 | | D | embedding | **スクリプトが自動管理** | | E | hash | **運用者が触る列と、スクリプトが管理する列を明確に分けています。**この境界が曖昧だと、手作業で壊されます。 ## 差分検知で再実行コストをほぼゼロに 実装上、最も効いた工夫です。 **行ごとに `sha256(質問+回答)` をhash列に保存し、不一致の行だけを再ベクトル化します。** 全件を毎回ベクトル化すると、API呼び出しが件数分発生します。**1行編集したら1行だけ処理する**——この差分検知により、更新コストがほぼゼロになりました。 実行のトリガーは2つ用意しています。 - スプレッドシートのカスタムメニュー（**「チャットボット > インデックス再構築」**） - **毎日4時の自動再ベクトル化トリガ** データ更新はリアルタイム不要という前提を確定させたうえでの設計です。 ## 三段構え判定 ``` 1. 質問を埋め込み（text-embedding-3-small / 1536次元） 2. 全行とコサイン類似度を取り、上位K=5件を抽出 3. 最大類似度 ≥ 0.7 かつ LLMが relevant=true と判定したときのみ回答 → 閾値未満・LLM不一致時は固定フォールバック文言 ``` **2つの条件を両方満たさないと回答しません。**数値的な近さと、意味的な妥当性の両方でフィルタしています。 LLM判定の出力を安定させる工夫もあります。**`response_format: json_object` と厳格なプロンプト指定により、出力を `relevant` と `index` の2フィールドに固定**しました。 **判定用途でLLMを使う場合、出力形式を固定しないと後続処理が壊れます。** ## GASの制約：署名検証ができない この構成で最も重要な制約であり、正直に記録しておくべき点です。 **GASの `doPost(e)` はHTTPヘッダにアクセスできません。そのため、LINE公式の `X-Line-Signature`（HMAC-SHA256）検証は実装できません。** この検証では代替として、**Webhook URLにクエリトークンを付与し、受信側で一致判定する簡易認証**を採用しました。 ただし、これは**署名検証と同等のセキュリティではありません。**共有シークレットをURLに乗せる方式であり、URLが漏れれば偽のリクエストを受け付けます。検証ログでも「妥協せざるを得なかった」と明記されています。 そのため、次の備えを残しています。 **HMAC署名検証のロジック自体は関数として残置し、GAS以外（Cloud Run等）への移行時にそのまま流用できる状態にしてあります。** **制約による妥協は、妥協だと分かる形で記録し、移行経路を用意しておくことが重要です。**本番運用で外部公開する場合は、署名検証が可能な実行環境への移行を前提に考えるべき部分です。 ## 再送ループを起こさない Webhookを扱う際の必須知識です。 **`doPost` は例外時もHTTP 200（`{ok:false, reason}`）を返します。** 理由は明確です。**LINEは非2xxのレスポンスで再送するため、エラー時に5xxを返すと処理が嵐になります。** エラーの詳細はレスポンスではなく、ログに残します。**「エラーを伝える先」と「処理を受け付けたことを伝える先」を分ける**設計です。 ## ログを2系統で持つ デバッグ効率を大きく左右した判断です。 **処理経路の各イベントを「ログ」シートに構造化JSONで追記し、標準のログ機能と二系統で追跡可能にしました。** 効果として、**標準ログだけでは追いにくい本番挙動（特にLINE側からの実リクエストの形状）を即座に俯瞰できました。** **外部サービスからのWebhookは、ドキュメントどおりの形で来るとは限りません。**実際に届いたものを見られる仕組みを最初に作っておくと、切り分けが速くなります。 ## 実装上のTips | 項目 | 知見 | | --- | --- | | **CacheServiceの100KB上限** | シリアライズ後サイズで判定し、超える場合は**無条件にシート直読みへフォールバック**する実装が安全 | | **embedding列の見た目** | JSON文字列のままだと行高が伸びて視認性が下がる。**書き込み後に `WrapStrategy.CLIP` と既定行高への再整形を挟む** | | **推論モデル系のAPI仕様** | `temperature` は既定値のみ受け付ける場合がある。**指定しない実装にしておくとモデル切替時の事故を防げる** | 2つ目は地味ですが実務的です。**運用者が毎日見る画面が崩れると、それだけで使われなくなります。** ## コード構成 役割を4ファイルに分離しています。 - `main.js` — doPost / リクエスト検証 / LINE返信 / オーケストレーション / ロガー - `Config.js` — 設定値アクセサ・動作パラメータ（モデル名・閾値・キャッシュTTL等） - `Embedding.js` — 埋め込みAPI呼び出し - `Knowledge.js` — インデックス構築 / 検索 / 判定 / 回答 / テスト / メニュー・トリガ **責務が分離されていることで、後続のスケール検証や置き換え（専用ベクトルDB化等）に向けた拡張ポイントが見えやすくなります。** なお、認証情報はScript Propertiesのみに保存し、リポジトリに乗らない構造にしています。 ## 残っている課題 - **回答精度の本格評価が未完了** - **現行20数件規模では類似度閾値（0.7）の妥当性が判断しきれない**——件数が増えるとスコア分布が変わる可能性がある - ナレッジが数百〜数千件規模に拡大した際のスケール耐性が未測定（キャッシュ上限・全件計算コスト・スコア分布） - マニュアル文書をQ&A形式に分解するチャンキングが属人的 2つ目は重要な指摘です。**閾値はデータ量によって適切な値が変わります。**少数のデータでチューニングした値が、増えた後も有効とは限りません。 ## よくある質問 ### 中継ツールを外すメリットは何ですか？ **構成要素が減り、運用窓口がスプレッドシートだけに絞られることです。**ユーザー体験の面でも、通常のLINEチャット内で完結します。 ### GASで署名検証はできますか？ **できません。**`doPost(e)` がHTTPヘッダにアクセスできないためです。この検証ではクエリトークンによる簡易認証で代替していますが、署名検証と同等のセキュリティではありません。本番運用では、署名検証が可能な実行環境への移行が前提になります。 ### Webhookでエラー時に何を返すべきですか？ **200を返し、エラー詳細はログに残してください。**非2xxを返すと再送が発生し、処理が繰り返されます。 ### データが増えたらどうしますか？ **キャッシュ上限を超えた場合はシート直読みへ自動フォールバックします。**数百件超の規模では、専用ベクトルDBへの移行を検討する設計になっています。 ## まとめ - 中継を外して**構成要素を「LINE / GAS / スプレッドシート / OpenAI」だけに絞る**と、運用が回る - **運用者が触る列とスクリプトが管理する列を明確に分ける** - **hashによる差分検知**で、更新時の再ベクトル化コストがほぼゼロになる - 判定は**類似度閾値とLLM判定の両方を満たしたときのみ回答**。出力形式はJSONで固定する - **GASでは署名検証ができない。**簡易認証は妥協であることを明示し、移行経路を残しておく - Webhookは**エラー時も200を返す**。非2xxは再送ループを招く - **実リクエストの形状を見られるログを最初に作る**と切り分けが速い - 閾値は**データ量が変わると適切な値も変わる** 仕組みを作るときは、機能を足すより構成要素を減らすほうが運用は安定します。誰がどこを触るのかが1箇所に収まっているかどうかが、続くかどうかを決めます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のチャットボット・RAG導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 画像生成からコードまでAIで完結させたら｜Figma MCP経由のLP制作で見えた限界 - URL: https://ai-katsu.jp/articles/figma-mcp-imagen2-lp - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-19T00:00:00+00:00 - Models: Claude Code, Imagen - Tools: Figma, MCP - Tasks: 資料作成・デザイン, 業務プロジェクト - Domain: マーケティング > 「画像生成 → Figmaでデザイン → MCP経由でコード化」というワークフローを実際に回しました。動くものを見ながら認識合わせできる価値は確かにある一方、出力コードはベタ書きでレスポンシブは全く対応できていません。定型部分はFigmaを経由しない方が早い、という発見もまとめています。 「画像生成 → Figmaでデザイン → AIがコード化」というワークフローは、記事や動画では完璧に見えます。実際に自分の手で回すと、**どこに価値があり、どこが足りないか**がはっきりします。 この検証では、そのフローを再現しました。**動くものが早く出る価値は確かにある。ただしレスポンシブは全く対応できていない**——というのが率直な結果です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月19日〜（検証中） | | ワークフロー | 画像生成 → Figmaでデザインおこし → **Figma MCP経由でClaude Codeがコード化** | | 実装 | React 19 + Vite 6 + TypeScript | | 作ったもの | LPのヘッダーメニューとファーストビュー（Header / Hero / StatsBar、生成画像6点） | | 条件 | **エージェントスキルなしで実施**（素の状態での実力を見るため） | | 状況 | 進行中 | ## 結論：価値は「動くものを見ながら作れる」こと この検証で最も明確に感じた価値です。 **従来はFigmaやMiroで「こんなイメージ」とポチポチしていた認識合わせを、実際に動く成果物を見せながら進められます。** 企画の初期段階で効きます。**静止画で合意したつもりでも、動かしてみると認識がずれていることは頻繁にあります。**動くものを起点にすれば、そのズレを早い段階で潰せます。 想定される使いどころは次のとおりです。 - **デザイナー → エンジニアへのラフ受け渡し**（「ファーストビューでこんなの作りたい、どうできそう？」） - **非エンジニア・デザイナー・ディレクターが顧客に「こんなのどうですか」と渡す**用途 ## 何を画像にし、何を再構築するか 実装方針として明確な線引きをしています。 | 要素 | 扱い | | --- | --- | | **生成画像系**（背景・見出し・ダッシュボードUI・ロゴ・アイコン・統計バー） | **画像アセットとして忠実配置** | | **ナビ・ボタン・CTA** | **実テキスト/実ボタンで再構築** | **「stylizedな部分は画像、テキスト/インタラクションは再構築」**という切り分けです。 これは実用的な判断です。**装飾的な部分を画像で置けば見た目が早く出ますが、押せるべきものは実装しないと動きません。**全部を画像にすると、見た目だけのモックになります。 ## Figma変数がなくても実装できた 技術的な発見です。 **Figma変数が未定義（全て生成ラスター画像）の状態でも、スクリーンショットのネイティブ解像度PNGをアセットとして使えば実装可能でした。** Figma MCPのread系（メタデータ取得 / スクリーンショット取得 / 変数定義取得）でデザイン構造とアセットを取得できることを確認しています。 **デザインデータが整っていなくても、見た目の情報さえ渡せば形にはなります。**ただしこれは、後述する品質の問題にもつながります。 ## できていないこと この検証の価値は、限界を明確にした点にあります。 - **出来上がったコードはほぼベタ書きで、コンポーネント分割が甘い**（エンジニア目線では要改善） - **レスポンシブデザインに全く対応しきれていない**——画面縮小時に強く感じる - 素材の作り込み不足により違和感のある箇所が残る 2つ目が最大の課題です。**PCで見た目が完成していても、スマホで崩れます。**実務のLPではモバイルのほうが重要なことが多く、これは致命的です。 対策として挙げられているのは次の2点です。 - **PC/スマホなど各サイズのバージョンを作り分けて読み込めるようにする** - **画面縮小時にメニューが見切れる場合、ハンバーガーメニューで開閉できるようにする** **レスポンシブは後から足すものではなく、設計初期から組み込む必要があります。**画像ベースで作ると、この設計が抜けやすくなります。 ## Figmaを経由しないほうが速い場面がある ワークフロー全体を見直す発見です。 **わかりやすい定型部分は、最初にFigmaでデザインを作るより、AIにプロンプトで指示して作らせた方が早い場面があります。** ヘッダーやフッター、よくあるセクション構成など、**「よくある形」が決まっているものはデザインを起こす工程自体が無駄になります。** 一方、ファーストビューは**「ラフ画像 → 生成 → コード化ツールに持ち込み → Figmaにデザイン投入」**の順が機能したと記録されています。 **全部を同じフローに乗せる必要はありません。**要素によって最短ルートが違います。 ## 差別化は「デザインの言語化力」に移る この検証で得た所感として、最も本質的な部分です。 **Figmaの作り方・使い方も含めた単純作業はAIに代替され得る。デザイン未経験者でも少し学べば一定品質のものを作れる可能性がある。** そのうえで、残る価値はこう整理されています。 **「良いデザインとは何か」を言語化し、AIに伝えられる力（デザイン原則の理解）を磨くことが重要。** ツールを操作する技能ではなく、**出てきたものを評価し、どう直すかを言葉にできること**が差別化要素になる——という見立てです。 ## 次の検証：別ツールでの再現 この検証では、次の比較検証も計画されています。 | | 現状フロー | 検証案フロー | | --- | --- | --- | | 画像生成 | ブラウザ版で生成 | 別ツール内で生成 | | デザイン | Figmaにインポートして調整 | 可能なら画像を逆輸入して調整 | | 実装 | MCP接続して書き出し | 同一ツール内で実装 | | 微調整 | — | **プレビューを見ながらパディング/マージン等を指示** | 検証の焦点は明確です。**「プレビュー連動の見た目調整によって、今回課題となったレスポンシブ問題がどこまで解決できるか」**です。 **画面を見ながら直せる環境なら、崩れに気づいて修正できるのではないか**——という仮説の検証になります。 ## よくある質問 ### このワークフローの価値はどこにありますか？ **企画初期の認識合わせです。**静止画ではなく動く成果物を見せながら合意形成できるため、齟齬を早い段階で潰せます。ラフの受け渡しや、顧客への初期提示に向いています。 ### 出力されたコードはそのまま使えますか？ **使えません。**ベタ書きでコンポーネント分割が甘く、レスポンシブにも対応していません。ラフ確認用途と割り切るのが現実的です。 ### Figmaは必ず必要ですか？ **定型部分は不要な場合があります。**よくある形が決まっているセクションは、デザインを起こすよりプロンプトで直接作らせた方が早いことがあります。 ### デザインスキルは不要になりますか？ **ツール操作のスキルは代替されますが、判断力は残ります。**「良いデザインとは何か」を言語化してAIに伝えられる力が、差別化要素になります。 ## まとめ - 価値は**「動くものを見ながら作れる」**こと。企画初期の認識合わせで効く - 実装方針は**「装飾は画像、テキスト/インタラクションは再構築」**の切り分け - **Figma変数が未定義でも、スクリーンショットをアセットとして使えば実装できる** - 課題は**ベタ書きのコード**と**レスポンシブ未対応**。特に後者は設計初期から組み込む必要がある - **定型部分はFigmaを経由せず直接プロンプトで作らせた方が早い**場面がある - 単純作業は代替されるため、**差別化は「デザインの言語化力」に移る** 新しいワークフローは、実際に回してみるまで何が足りないか分かりません。ラフ確認用途と本番実装は別物と割り切ると、使いどころが見えてきます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のWeb制作へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## チャットボット案件（スプレッドシート×埋め込みモデル） 検証してみた - URL: https://ai-katsu.jp/articles/xksd7h - Author: 田中省伍 (@s-tanaka-4e4010) - Published: 2026-05-17T08:45:10.468+00:00 - Models: claude-haiku-4-5 - Tools: dify - Tasks: Dify, RAG, チャットボット - Domain: 業務効率化 📋 プロジェクト概要 * カテゴリ: チャットボット / RAG（簡易ベクトル検索） * 期間: 2026/05/17 -（検証中） --- ## 1. 背景と目的 * 新規チャットボット案件。利用者が3つの選択肢から順に回答し、最後に質問を入力するフローが求められている。 * クライアントはDifyのナレッジベースを直接操作せず、Googleスプレッドシート上でのデータ管理を希望。Difyの操作をせずスプレッドシートのみで完結する運用を求めている。 * 本案件はLINEでの利用を想定。リッチメニュー経由での質問受付を確認しつつ、質問入力用の画面が別途必要という整理。 * Difyのナレッジ機能を使わずに、どう回答精度を担保するかが議論の中心的な論点。 --- ## 2. 取り組み内容 ### 実施した施策・活動 * チャットボット案件の技術構成と運用要件を協議し、Googleスプレッドシート＋埋め込みモデルを用いた実装方針を決定。 * Difyの開始ブロックにプルダウン形式の入力フィールドを追加しカテゴリ選択させる設定を、実機で確認。 * 3段階の開発工程（①スプレッドシート項目定義 ②埋め込みモデル呼び出しGAS構築 ③全体統合）を確認・合意。 ### 使用したツール・技術 * Googleスプレッドシート（データ管理＋簡易ベクトルDB） * Google Apps Script（GAS）：差分検知・埋め込みAPI呼び出し・ベクトル処理・OpenAI API直叩き * 埋め込みモデル（Embedding Model）：テキストの数値化・意味の近さ判定 * 大規模言語モデル（LLM／OpenAI API）：抽出候補の最終判定 * Dify：開始ノードでカテゴリ選択入力、Web公開URLでLINE→Web回答画面へ誘導 * LINE：リッチメニュー／チャット画面からの導線 ### 主要な意思決定とその理由 * スプレッドシート＋GASを軸としたシステム構成を採用（クライアント要件＝Dify非操作・スプレッドシート完結のため）。 * DifyのWeb公開URL機能を利用し、LINEのチャット画面からWebの回答画面へ誘導する仕様に合意。Difyの開始ノードからGASへデータを中継する構成で実装。 * キーワード検索の限界に対し、埋め込みモデルでベクトル化＋コサイン類似度で回答候補を抽出する方式を導入。 * 抽出した上位候補（例：5件）に対しLLMで適切性を判定。マッチングスコアが一定（例：0.7以上）を超えた場合のみ回答を返す制御。 * スプレッドシートの差分を監視し、埋め込みモデルでベクトル化して保存する構成。数百行規模ならGAS運用が可能。 * データ更新はリアルタイム不要。1日1回等の定期実行、または運用担当者の手動実行で対応。 * OpenAI APIはK W社アカウントの余剰枠を活用するため、GAS側から直接呼び出す構成とする。 * Dify開始ブロックのカテゴリ選択入力を必須化し、入力ミス防止とデータ整理を両立。 --- ## 3. 進捗と成果 ### 達成できたこと * GAS／スプレッドシート／埋め込みAPI／LLMを組み合わせたシステム全体像と開発フローのイメージが明確化。 * 3ステップの開発工程と次回までの役割分担を合意。 ### 定量的な成果 * （情報なし） ### 定性的な成果 * 今回の議論を通じてシステム構築のイメージ・全体像が明確になり、今後の進め方の見通しが立ったとの確認。 --- ## 4. 学びとナレッジ ### うまくいったこと（Good） * 埋め込みモデル＋コサイン類似度の導入で、単純なキーワード一致より高い正答率が期待できるという方針整理ができた。 * 実機でDify開始ブロックのプルダウン設定を確認でき、認識を揃えられた。 ### うまくいかなかったこと（Bad） * （情報なし） ### 改善ポイント（Improve） * （随時更新） ### 技術的な発見・Tips * 埋め込みモデルはキーワード一致でなく「意味の近さ」を数値で判定でき、関連性の高い回答抽出に有効。 * スプレッドシートを簡易ベクトルDBとして使い、数百行規模ならGASで運用可能。データ増加時もベクトルDBに近い検索へ寄せられる余地がある。 * 抽出候補に対するLLM判定＋スコア閾値（例：0.7）で、回答可否を制御できる。 --- ## 5. 課題と対応 ### 発生した課題 * ユーザーの質問がスプレッドシート上の既存データと完全一致しないケースの判定方法。単純なキーワード検索では限界がある。 * GPT／GeminiのAPIを都度呼び出すと将来的にコストが増大するリスク。 * 埋め込みモデルとLLMは異なる軸で運用され、それぞれにAPI利用料が発生（二重課金）。埋め込みモデルを選択できない環境ではコスト・運用の複雑さが課題。 * LLM利用は検索品質が上がるが管理が煩雑、キーワード検索は品質が下がるが管理が容易、というトレードオフ。 ### 対応方法 * 埋め込みベクトル化＋コサイン類似度＋LLM最終判定の三段構えで精度とコストを両立させる方針。 * LLMのAPI利用に集約する選択肢も比較検討対象とし、現構成と運用コストの観点で最適解を継続検討。 ### 未解決の課題 * 埋め込みモデルとLLMの最終的なコスト配分・構成の最適解 --- ## 6. コストとリソース ### 人的リソース * リサーチに１H、実装に５H ### 金銭的コスト * 埋め込みモデルとLLMで別軸のAPI利用料が発生する ### コスト対効果 * （マニュアルに従って動くだけの）チャットオペレータの人件費が割愛できるコスト効果 --- ## スプレッドシートを簡易ベクトルDBにする｜FAQボットの精度を保つ三段構え設計 - URL: https://ai-katsu.jp/articles/chatbot-spreadsheet-embedding - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-17T00:00:00+00:00 - Models: OpenAI API - Tools: Google Apps Script, Dify, LINE - Tasks: ナレッジ活用・RAG, 業務プロジェクト - Domain: マーケティング > 専用のナレッジベース機能を使わず、スプレッドシートでのデータ管理のみで回答精度を担保する構成を設計しました。埋め込みベクトル化 → コサイン類似度で候補抽出 → LLMで最終判定という三段構えと、スコア閾値による「返さない」判断の設計をまとめています。 チャットボットのFAQを運用する現場では、しばしば矛盾した要件が出てきます。**「回答精度は上げたい。ただしデータはスプレッドシートで管理したい」**——専用のナレッジベース機能を使わずに、精度をどう担保するか。 この検証では、**スプレッドシートを簡易ベクトルDBとして使う**構成を設計しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月17日〜（検証中） | | やりたかったこと | 専用ナレッジベース機能を使わず、スプレッドシートでのデータ管理のみで回答精度を担保する | | 構成 | Googleスプレッドシート（データ管理＋簡易ベクトルDB）＋ GAS（差分検知・API呼び出し・ベクトル処理）＋ 埋め込みモデル ＋ LLM | | 方式 | **埋め込みベクトル化 → コサイン類似度で候補抽出 → LLMで最終判定**の三段構え | | 状況 | 設計合意・実装フェーズ | ## 結論：キーワード一致では足りない この設計の出発点は、明確な課題認識です。 **ユーザーの質問がスプレッドシート上の既存データと完全一致しないケースをどう判定するか。単純なキーワード検索では限界があります。** FAQは「登録した言い回し」で質問されるとは限りません。同じことを聞いていても、言葉が違えばキーワード検索では引っかかりません。 そこで**埋め込みモデル**を使います。 **埋め込みモデルはキーワード一致ではなく「意味の近さ」を数値で判定できるため、関連性の高い回答抽出に有効です。** ## 三段構えの設計 ``` ① 埋め込みモデルでベクトル化 ↓ ② コサイン類似度で上位候補を抽出（例：5件） ↓ ③ LLMで候補の適切性を判定 ↓ スコアが閾値（例：0.7）を超えた場合のみ回答を返す ``` この構成のポイントは**「返さない」判断ができること**です。 **マッチングスコアが一定を超えた場合のみ回答を返す**——閾値を設けることで、無関係な回答を返すことを防げます。 FAQボットで最も避けたいのは、見当違いの回答を自信満々に返すことです。**「該当する回答が見つかりません」と言えるほうが、信頼を損ないません。** ## スプレッドシートを簡易ベクトルDBとして使う この構成が成立する条件も整理しています。 **スプレッドシートを簡易ベクトルDBとして使い、数百行規模ならGASで運用可能です。** 専用のベクトルDBを立てると、インフラが1つ増えます。運用担当者が触れない場所にデータが移り、管理の手間も増えます。 **データ量が限られているなら、既に運用されている場所の上に載せるほうが定着します。** データ量が増えた場合は、本格的なベクトルDBへ移行する余地も残しています。**最初から大きく作らず、必要になったら移す**という設計判断です。 ## 更新はリアルタイムでなくてよい 運用設計上の重要な割り切りです。 **スプレッドシートの差分を監視し、埋め込みモデルでベクトル化して保存する構成。データ更新はリアルタイム不要で、1日1回等の定期実行、または運用担当者の手動実行で対応します。** FAQの内容が変わるのは、頻繁ではありません。**更新を即時反映する仕組みを作ると、その分だけ構成が複雑になり、API呼び出しも増えます。** **「どのくらいの鮮度が必要か」を先に確認すると、設計が簡単になります。** ## 二重課金という論点 この構成で残る課題です。 **埋め込みモデルとLLMは異なる軸で運用され、それぞれにAPI利用料が発生します。** | 方式 | 検索品質 | 管理の手間 | | --- | --- | --- | | LLM利用 | 上がる | 煩雑 | | キーワード検索 | 下がる | 容易 | **品質と管理容易性はトレードオフになります。**この検証では、埋め込み＋類似度＋LLM判定の三段構えで両立を狙う方針をとりました。 ただし**最終的なコスト配分・構成の最適解は継続検討**としています。LLMのAPI利用に集約する選択肢も比較検討の対象です。 **「精度が上がる構成」が必ずしも最適とは限りません。**運用コストと管理の手間を含めて判断する必要があります。 ## 入力の設計：カテゴリ選択を必須にする 精度を上げるもう1つの工夫です。 **開始時のカテゴリ選択入力を必須化し、入力ミス防止とデータ整理を両立させます。** 自由入力だけに頼ると、検索対象が全データになります。**先にカテゴリで絞り込めば、候補が減り、精度が上がります。** ユーザーにとっても、選択肢から選ぶほうが「何を聞けばいいか」が分かりやすくなります。 ## チャネル間の導線設計 実装上の構成として整理された点です。 チャットアプリのリッチメニューから質問を受け付ける想定ですが、**質問入力用の画面が別途必要**という整理になりました。 対応として、**Web公開URL機能を利用し、チャット画面からWebの回答画面へ誘導する**仕様を採用しています。 **すべてを1つのチャネル内で完結させようとすると、UIの制約に引っかかります。**入力が複雑になる部分だけWebに逃がす、という割り切りが現実的です。 ## 開発工程を3つに分ける 進め方も整理されています。 1. **スプレッドシートの項目定義** — 不要な列を削除し、運用に必要な項目のみでシート構造を決定 2. **埋め込みモデル呼び出しのGAS構築** — 決定したシート構成に基づくスクリプト 3. **全体統合** 順番が重要です。**シート構造を先に確定させてから、それを扱うコードを書きます。**逆にすると、構造が変わるたびにコードを直すことになります。 ## よくある質問 ### なぜ専用のナレッジベース機能を使わないのですか？ **運用側がスプレッドシートで完結させたいという要件があるためです。**データを触る人が普段使っているツールから離れると、更新されなくなるリスクがあります。 ### スプレッドシートでベクトル検索ができるのですか？ **数百行規模ならGASで運用可能です。**埋め込みベクトルをシートに保存し、コサイン類似度で候補を抽出します。データが増えた場合は本格的なベクトルDBへの移行余地を残しています。 ### 無関係な回答が返るのを防げますか？ **スコア閾値（例：0.7）を設けることで制御できます。**閾値を超えた場合のみ回答を返し、超えなければ「該当なし」とする設計です。 ### コストが心配です **埋め込みモデルとLLMで別々にAPI利用料が発生する点が論点です。**データ更新をリアルタイムにせず定期実行にすること、カテゴリ選択で検索範囲を絞ることが、呼び出し回数の抑制につながります。 ## まとめ - FAQ検索では**キーワード一致に限界がある。**埋め込みモデルで「意味の近さ」を判定する - 構成は**ベクトル化 → コサイン類似度で候補抽出 → LLMで最終判定**の三段構え - **スコア閾値を設けて「返さない」判断ができる**ようにする - **数百行規模ならスプレッドシートを簡易ベクトルDBとして運用できる。**既存の運用場所から動かさないほうが定着する - **更新はリアルタイム不要。**定期実行や手動実行で足りるかを先に確認する - 品質と管理容易性は**トレードオフ**。精度が高い構成が最適とは限らない - **カテゴリ選択を必須化する**と、検索範囲が絞られて精度が上がる チャットボットの精度は、モデルの性能だけでは決まりません。どう絞り込み、どこで返さない判断をするかの設計が結果を左右します。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のチャットボット・RAG導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## image2.0で全てのスライド制作が爆速になった件 - URL: https://ai-katsu.jp/articles/image2-0-jog1j3 - Author: 鍛高譚水割り (@aibou-01) - Published: 2026-05-14T17:51:26.521+00:00 - Models: image2.0 - Tools: chatgpt, Canva - Tasks: スライド制作, image2.0, ChatGPT - Domain: クリエイティブ > XDとか使ってデザイン素材を作成して、運用はCanvaでやっていたのでかなり工数がかかっていたのでどうにかならないかと思っていました。 ## 背景・やりたかったこと XDとか使ってデザイン素材を作成して、運用はCanvaでやっていたのでかなり工数がかかっていたのでどうにかならないかと思っていました。 ## 使ったAI - chatgpt - Canva ## 大変だったこと 特に大変なポイントはなかったですが、リファレンスの重要性と制限をうまくかける部分が工夫が必要でした。というのも、AIの特性上余白を作らない性質があるので、制限をかけないと何でもかんでも埋めてしまうのはモデルの精度が上がってもそれは変わらないんだなというところで、工夫ポイントって感じでした。 ## やったこと 1.参考にしたいスライドのリファレンスを見つける(URLでもスクショでもOK) 2.CahtGPTで添付した参考のスライドをもとに下記のタイトルのスライドを作成してと指示 3.出てきたスライドを見て修正があれば修正 4.Canvaや他のスライドにコピペで貼り付け 5.以上 ## 結果 デザイン制作・要素作成3H → 15分 もう、たまげた ## スクリーンショット ![スクリーンショット 2026-05-15 2.47.12](https://hfkxiiphuaekupubgoug.supabase.co/storage/v1/object/public/article-images/75a0774b-099c-4499-b45f-64eeab7e8139/1778780856056-a1rb4o01.png) --- ## SNS運用はどこまでAIに任せられるか｜工程別の実用度と2026年5月時点の線引き - URL: https://ai-katsu.jp/articles/sns-research-automation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-14T00:00:00+00:00 - Models: Gemini - Tools: TikTok, Instagram, YouTube Data API - Tasks: リサーチ・データ収集, ツール検証 - Domain: マーケティング > SNSリサーチ業務を工程に分解し、どこまで自動化できるかを整理しました。動画解析は60秒$0.009でコストがボトルネックでなくなった一方、予約投稿は依然API未対応でドラフト止めが標準。AIは「何が起きているか」は分析できても「なぜ伸びたか」は出せない、という線引きをまとめています。 SNS運用の自動化は「できる/できない」で語られがちですが、実際には**工程ごとに実用度がまったく違います。**そして制約の多くは技術ではなく、**各プラットフォームのAPI提供状況と規約**にあります。 この調査では、SNSリサーチ業務を工程に分解し、**どこまでAIで自動化できるかの線引き**を整理しました。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 作成日 | 2026年5月14日（5月15日更新） | | やりたかったこと | SNS運用代行のリサーチ工程を「どこまでAIで自動化できるか」見極める | | 調査した3観点 | ①トレンド収集API ②動画中身のVLM解析 ③自動投稿・運用分析 | | 結論 | **動画解析は実用ラインに到達／投稿はドラフト止めが標準／トレンド収集は第三者依存とToSリスクが残る** | > 本記事の各種仕様・価格は2026年5月時点の調査に基づきます。SNSプラットフォームのAPI仕様・規約は変更が頻繁なため、実装前に必ず公式情報をご確認ください。 ## 結論：工程別の実用度マトリクス | 工程 | 実用度 | 主要ボトルネック | | --- | --- | --- | | トレンド収集（メタ） | 高 | **公式APIなし、第三者依存・ToSリスク** | | 動画中身解析 | **高** | 実質解消。高速カットの精密検出のみ残課題 | | 企画・台本生成 | 高 | ブランドボイス調整は人力 | | 撮影・編集 | 低〜中 | **出演者・現場感は人力必須** | | 投稿 | **要注意** | **予約投稿API未対応、規約変化** | | 運用分析・レポート | 高 | 新メトリクス追加で精度向上 | | 改善提案 | 中 | **文化的解釈・戦略判断は人力優位** | **実用度が低いのは、技術的に難しい工程ではありません。**撮影は現場が必要だから、投稿はAPIが対応していないから——理由はそれぞれ別です。 ## 動画解析：コストがボトルネックでなくなった この調査で最も大きな変化があった領域です。 **60秒の動画で約18,000トークン、1本あたり約$0.009。**週100本を解析してもモデル側のコストは約$1/週に収まります。 「動画をAIに見せて分析させる」ことが、**コスト面で気軽に試せる水準になった**という意味です。 ### できること・できないこと | タスク | 可否 | | --- | --- | | 最初3秒のフック構造分析 | **可能**（精度が大幅向上） | | カット切替検出（秒単位） | 可能 | | テロップ（日本語OCR） | 可能 | | 音声書き起こし（日本語） | 高精度で可能 | | BGM検出（曲名特定） | 部分的 | | 出演者属性 | 可能（**プライバシー注意**） | | 高速カット（<0.5秒）の精密検出 | 困難だが改善余地あり | | **「なぜ伸びたか」の因果解釈** | **不可**（相関把握まで） | | **戦略提案** | **不可** | 最後の2行が本質です。**AIは「何が起きているか」は分析できますが、「なぜ伸びたか」の因果は出せません。**相関の指摘までです。 **分析を自動化しても、解釈と判断は残ります。**ここを混同すると、出力された相関をそのまま施策に落として失敗します。 ### フレームレートの設定 技術的な要点として、**動画解析はデフォルト1FPSで処理され、最大10FPSまで指定できます。** トークン消費は標準解像度で約300トークン/秒、低解像度で約100トークン/秒です。**高速なカット割りを検出したい場合はFPSを上げる必要がありますが、その分コストも増えます。** ## 用途で使い分けるモデル | 用途 | 選択肢 | | --- | --- | | **個別動画の内容解析** | 汎用のマルチモーダルモデル（コスト・精度のバランスが最良） | | **大量動画のインデックス・類似検索** | 動画特化の専用エンジン（インデックス $0.042/分） | | **セグメント自動分類**（フック/本編/CTAの分離） | 動画特化エンジンのセグメンテーション機能 | | セルフホストしたい場合 | オープンなVLM（APIコスト不要、長時間動画の秒単位検索に対応） | あわせて確認できた重要な事実があります。**動画ファイルの直接入力に対応していないモデルもあります。**テキストや画像には対応していても、動画は非対応というケースです。 **この場合は「文字起こし後のスクリプト分析」や「企画立案の補助」に用途を寄せる**という使い分けになります。 ## トレンド収集：公式APIが使えない現実 ここが最も制約の大きい領域です。 **主要な短尺動画プラットフォームの研究用APIは、2026年5月時点でも日本での商用利用ができません。**対象が特定地域の非営利学術研究者に限られており、要件はむしろ厳格化しています。 実務的な選択肢は第三者サービス経由になりますが、ここにリスクがあります。 **2026年4月に、特定のデータへのプログラマティックなスクレイピングがToS違反として明記強化されました。** **「技術的にできる」ことと「規約上できる」ことは別です。**特に業務として継続する場合、この確認は必須になります。 なお、第三者サービス側では**MCP対応が追加され、AIエージェントから直接呼び出せるようになっている**という動きもあります。 ## 投稿：予約投稿が依然としてAPI未対応 自動化を阻む具体的な制約です。 2026年に投稿APIへ多くの機能が追加されました。 - Duet/Stitch許可フラグの指定 - ブランデッドコンテンツ開示フラグ - ジオターゲティング（地域別視聴可否） - Webhookコールバック（アップロードステータスの非同期通知） - 写真投稿対応 しかし、**予約投稿（scheduled\_publish\_time）は依然としてAPI未対応**です。選べるのは「即時公開」か「ドラフト保存」の2択になります。 結果として、**ドラフト止め＋人力投稿が業界標準**という状況です。 ### 海外エージェンシーの標準ワークフロー ``` AI生成 → 4点チェック（ファクト / ボイス / コンプラ / CTA）→ 承認 → 手動スケジュール投稿 ``` この形で**週20〜30投稿の運用が、週15時間から4時間に短縮された事例**があります。 **投稿そのものを自動化できなくても、その前工程を自動化すれば効果は出ます。**「全自動でなければ意味がない」という発想では、この改善を取り逃します。 ## API料金体系の変化に注意 コスト設計に直結する変化です。 あるプラットフォームでは2026年に従量課金へ全面移行し、さらに料金改定が行われました。 | 操作 | 変化 | | --- | --- | | 自分の投稿・フォロワー等の読み取り | **$0.001/req に値下げ** | | 通常の書き込み（URLなし） | $0.010 → $0.015/req | | **URL付き投稿** | **$0.20/req（+1,900%）** | | フォロー・いいね・引用 | セルフサーブAPIから除外 | **URL付き投稿が20倍近くに値上げされたことで、自動拡散系の仕組みは経済的に成立しなくなりました。** 一方で**自社投稿の分析コストは下がっています。**「拡散を自動化する」用途は締められ、「自社データを分析する」用途は開かれた——という方向性が読み取れます。 ## 運用分析：新メトリクスが本丸 2026年4月の大きな変化です。 **3秒スキップ率（Skip Rate）がGraph APIで正式提供**されるようになりました。あわせてクロスポスト再生数、リポスト数、保存数、シェア数も取得可能になっています。 スキップ率が取れると何が変わるか——**「最初の3秒で離脱されているか」が数値で分かります。**フックの改善ループを、感覚ではなくデータで回せるようになります。 **分析の自動化で効いてくるのは、取れる指標が増えることです。**ダッシュボードを作る技術より、何を測れるかが先にあります。 ## 推奨パイプライン ### フェーズ1：解析の最小構成 ``` トレンドハッシュタグ取得（MCP経由でAIエージェントから直接） → ハッシュタグ別の上位動画取得 → 動画ダウンロード → VLMでフック・カット・テロップ・出演者・BGM特徴を解析 → データベース or スプレッドシートへ保存 ``` **週100本の解析でモデル側コストは約$1/週。**まずここから始めるのが現実的です。 ### フェーズ2：投稿運用 - **投稿は手動を継続**（予約投稿API未対応、リーチ低下リスクも残る） - AI生成ドラフトは1箇所に集約し、4点チェックフローで承認後に手動投稿 ### フェーズ3：運用分析 - スキップ率APIを取り込み、フックの改善ループに活用 - Insightsをダッシュボードツールへ接続し、週次レポートを半自動化 ## 残っている検証課題 - **API経由投稿のリーチ低下を示す実証データ**は、公式・第三者ともに未確認 - 高速カット（<0.5秒）の見落とし率の実測 - 日本語テロップOCR精度の実測 1つ目は重要です。**「API投稿はリーチが下がる」という話は広く言われていますが、実証データは確認できていません。**通説として扱い、断定は避けるべき領域です。 ## よくある質問 ### SNS運用はどこまで自動化できますか？ **リサーチ・解析・企画・分析は実用水準ですが、撮影と投稿は人力が残ります。**特に投稿は、予約投稿がAPI未対応のため「ドラフト止め＋人力投稿」が標準です。 ### 動画解析のコストはどのくらいですか？ **60秒動画で1本あたり約$0.009です。**週100本の解析でも約$1/週に収まります。コストは実用上のボトルネックではなくなりました。 ### AIは「なぜ伸びたか」を分析できますか？ **できません。**何が起きているかの相関把握までです。因果の解釈と戦略提案は人力が優位な領域として残ります。 ### 第三者のデータ取得サービスを使っても大丈夫ですか？ **ToSの確認が必要です。**2026年4月に、特定データへのプログラマティックなスクレイピングがToS違反として明記強化されています。業務で継続利用する場合は特に注意が必要です。 ## まとめ - SNS自動化の制約は**技術ではなくAPI提供状況と規約**にある - **動画解析はコストがボトルネックでなくなった**（60秒$0.009、週100本で約$1） - AIは**「何が起きているか」は分析できるが「なぜ伸びたか」は出せない** - **予約投稿は依然API未対応。**ドラフト止め＋人力投稿が業界標準 - 投稿を自動化できなくても**前工程の自動化で週15時間→4時間の短縮事例**がある - API料金改定により**自動拡散系は経済的に成立しなくなった**一方、自社分析のコストは下がった - **3秒スキップ率の正式API提供**で、フック改善をデータで回せるようになった 自動化の検討では、まず工程を分解して実用度を確認すると判断が早くなります。全部を自動化しようとするより、効く工程を選ぶほうが結果が出ます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 補助金情報の収集を自動化する｜手動30分を5分にしたブラウザ操作ワークフロー - URL: https://ai-katsu.jp/articles/jnet21-subsidy-search-workflow - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-10T00:00:00+00:00 - Models: Claude Code - Tools: Browser Use, Excel - Tasks: リサーチ・データ収集, ツール検証 > 公的な支援情報サイトから条件に合う補助金を自動取得し、色分けExcelに出力する仕組みを構築しました。「掲載日基準」と「募集期間基準」で結果が別物になる点、検索フォームのパラメータを解読してURLを直接組み立てる手法、日本語の日付表記の扱いまでまとめています。 補助金・助成金の情報収集は、条件を変えるたびに手作業でやり直しになります。「今月申請できるもの」を一覧にするだけで、毎回30分近くかかります。 この検証では、公的な支援情報サイトから**条件に合う補助金を自動取得してExcelに出力するワークフロー**を構築しました。**手動30分が自動5分**になっています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年5月10日（単日） | | 構成 | J-Net21（中小機構運営）+ Browser Use CLI + Claude Code + Python（openpyxl） | | やりたかったこと | 補助金情報の自動収集・フィルタリング・Excel出力を一気通貫で行う | | 成果 | **全131件から条件に合う56件を抽出してExcel出力**／Claude Codeスキルとしてパッケージ化 | | 所要時間 | 全5ページ取得**約15〜20秒**／対話含む総所要時間 約10分 | | 効果 | **手動30分/回 → 自動5分/回** | | 判定 | **即座に導入推奨**（★5/5） | > 対象は公的機関が運営する公開情報サイトです。取得にあたっては利用規約の範囲内で実施しています。 ## 結論：検索条件の「基準」で結果が別物になる この検証で最も実務的な発見です。 **「公開日基準」と「募集期間基準」で、まったく異なる結果になります。** | フィルタ基準 | 結果 | | --- | --- | | 掲載日基準（直近1ヶ月） | **67件** | | 募集期間基準（2026年5月に申請可能） | **56件** | 知りたいのはたいてい後者です。**「最近掲載された補助金」と「今申請できる補助金」は別物**だからです。掲載が古くても募集中のものは申請できますし、掲載されたばかりでも募集開始前のものがあります。 **この使い分けは最初に確認すべき項目です。**基準を間違えると、集めた一覧が目的に合いません。 もう1つ、データの性質として**「期間記載なし」が多数（67件）存在します。**通年型の制度が多いと見られます。 ## フォームのパラメータを丸ごと解読する 自動化の起点になった作業です。 **JavaScriptの実行でフォームを直接探索し、検索パラメータ（分野・種別・地域・期間・カテゴリ）を完全に解読しました。** 具体的な手法として、次が有効でした。 ``` document.querySelectorAll('input[type=checkbox]') → 全チェックボックスを name / value / label ごとに取得 ``` **検索フォームのUIを操作する代わりに、URLパラメータを直接組み立てる**という方針です。これができると、条件変更がURLの書き換えだけで済みます。 ページネーションも同様です。**ページ内のリンクを取得して実際のURL構造を確認**することで、正しい遷移方法が分かりました。 ## URLパラメータで効かないものもある 一方で、思い通りにいかない部分もありました。 **日付範囲フィルタ（startDate / endDate）はURLパラメータでは機能しません。** 対処は**Pythonで全件取得した後にフィルタする**という方針です。 **「サーバー側で絞れるものは絞る、絞れないものは取得してから絞る」**——この切り分けを早めに確認しておくと、無駄な試行錯誤を避けられます。 ## Browser Use CLIの基本パターン 安定して動いた操作の型です。 ``` browser-use open URL → sleep 2 → browser-use eval "JS" ``` **この3ステップが基本パターンとして安定します。**ページのロード前にJavaScriptを実行すると空配列が返るため、`sleep` を挟むことが必要でした。 また、この検証時点では以下の制約がありました。 | やりたいこと | 状況 | 代替手段 | | --- | --- | --- | | テキスト抽出 | `extract` コマンドは未実装 | `eval` + JavaScriptで代替 | | 待機 | `wait N（秒数）` は未対応 | シェルの `sleep 2` で代替 | | フォーム送信 | submitボタンをクリックすると別ページへ飛ぶ | URLパラメータを直接組み立てる | **専用コマンドがなくても、JavaScriptを実行できれば大抵のことはできます。**この柔軟性が `eval` の価値です。 ## 日本語の日付表記をどう扱うか 日本のサイトを扱う際に必要になる処理です。 **正規表現 `募集期間[：:]\s*(\S+?～\S+)` で日本語の募集期間表記を確実に抽出**できました。 ポイントは `[：:]` です。**全角コロンと半角コロンの両方に対応**させています。日本語のページでは表記が混在することがあります。 パース時は**年月日を `-` に置換してから `datetime.strptime(s, '%Y-%m-%d')` に渡す**という方法をとりました。 ## 出力はExcelで渡す 成果物の形式も重要な判断です。 - **色分け**（橙・黄・白/薄青） - **ヘッダー固定** - **2シート構成**（一覧＋検索条件シート） 検索条件をシートとして残している点が実務的です。**「この一覧はどういう条件で取ったのか」が後から分かります。**数ヶ月後に見返したとき、条件が分からないリストは使えません。 ## スキルとして再利用可能にする この検証は、単発の自動化で終わっていません。 **Claude Codeのスキルとして実装・パッケージ化**し、トリガーフレーズから即実行できる状態にしています。 また、処理を分割しているのも設計上のポイントです。 - `fetch_and_filter.py` — 取得とフィルタ - `create_excel.py` — Excel出力 **個別に呼び出せるようにしておくと、出力形式だけ変えたいときに取得部分を再利用できます。**中間データをJSONで持つことで、他ツールとの連携も可能になります。 ## コストと効果 | 項目 | 内容 | | --- | --- | | 初期設定 | 0分（CLIインストール済みの場合） | | 構築時間 | 約60分（パラメータ解析・スクリプト作成） | | 費用 | **ほぼ0円**（対象サイト無料・CLIはOSS・LLM利用料のみ） | | 削減効果 | 手動30分/回 → 自動5分/回（**25分削減**） | | 月次想定 | 週1回×4回で**月100分の工数削減** | **初回の利用で構築コストを回収できる計算**です。 ## 懸念点 - **ページ構造の変更（サイトリニューアル）に弱い** — JavaScriptの修正が必要になる - 認証が必要なサイトはセッション管理が別途必要 - `sleep` のタイミングはネットワーク環境により調整が必要な場合がある **スクレイピングベースの自動化は、相手側の構造に依存します。**壊れる前提で、修正しやすい形にしておくことが重要です。 ## よくある質問 ### 「今月申請できる補助金」を調べるには？ **掲載日基準ではなく募集期間基準でフィルタしてください。**この検証では掲載日基準67件に対し、募集期間基準では56件と結果が大きく異なりました。 ### 専用の抽出コマンドがなくても自動化できますか？ **できます。**JavaScriptを実行できれば、DOMから任意の情報を取り出せます。この検証でもフォームパラメータの完全解読からデータ抽出まで、すべて `eval` で行っています。 ### 取得結果が空になります **ページのロード前に実行している可能性があります。**`open` の後に `sleep 2` を挟んでください。 ### 他の用途にも使えますか？ **認証不要の公開サイトであれば同じ方法が適用できます。**検索条件をパラメータ化しておけば、条件を変えるだけで再利用できます。 ## まとめ - **「掲載日基準」と「募集期間基準」で結果が別物になる。**目的に合う基準を最初に確認する - 検索フォームは**UIを操作せず、パラメータを解読してURLを直接組み立てる** - **サーバー側で絞れないフィルタは、全件取得してから処理する** - 基本パターンは `open → sleep → eval`。**ロード前の実行を避ける** - 日本語の日付表記は**全角・半角コロンの両方に対応**させる - 出力には**検索条件シートを添える。**後から条件が分からないリストは使えない - **取得とExcel出力を分けておく**と、出力形式だけの変更が容易になる 公開情報の収集は、条件が固まっていれば自動化しやすい領域です。何を基準に絞るかを最初に決めておくと、そのまま繰り返し使える仕組みになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のリサーチ業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 文字起こしで勝手に要約させない｜Geminiのプロンプト設計と運用Tips - URL: https://ai-katsu.jp/articles/gemini-transcription-prompting - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-09T00:00:00+00:00 - Models: Gemini, Claude Code - Tasks: 音声・翻訳・文字起こし, ツール検証 > AIに文字起こしを頼むと、指示していないのに要約され書き言葉に整えられます。「要約・構成案を作らない」「話し言葉維持」「フィラーは除去するが内容は改変しない」という線引きを指示で固定する方法と、MP4の読込エラー回避、プロジェクト機能を使った運用までまとめています。 会議の文字起こしをAIに任せると、多くの場合**勝手に要約されます。**「議事録を作って」と頼んでいないのに、話し言葉が書き言葉に整えられ、構成案まで付いてくる。 この検証では、その挙動を抑えて**忠実な文字起こしを得るためのプロンプト設計と運用**を整理しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 作成日 | 2026年5月9日 | | 対象 | Geminiによる音声・動画の文字起こし運用 | | やりたかったこと | 要約されず、話し言葉のまま忠実に文字起こしさせる | | 成果 | ファイル前処理・プロンプト設計・ワークフローの運用Tipsを整理 | ## 結論：AIは放っておくと「整えて」しまう 文字起こしで最も重要なのは、**やってほしくないことを明示すること**です。 プロンプトに入れるべき条件は3つあります。 - **「要約・構成案を作らない／忠実に文字起こしする」を明示** - **書き言葉化を防ぐため「話し言葉維持・サンプル口調を継承」の条件を追加** - **フィラーは除去するが内容改変はしない、というバランスを指示で固定** 3つ目が微妙な調整です。**「えーと」のようなフィラーは消してほしいが、言い回しは変えてほしくない**——この線引きを指示で固定しておかないと、出力のたびに整えられ方が変わります。 **話し言葉のまま残すことには意味があります。**誰がどう言ったかのニュアンスは、書き言葉に整えた時点で失われます。 ## マルチモーダルで音声・動画を直接扱える ツール選定の観点です。 **Geminiはマルチモーダルで音声・動画を直接解析できます。**他のモデルでは音声の直接処理に制約がある場合があり、この点が使い分けの理由になります。 ## ファイル前処理でつまずかない 地味ですが実務で効く知見です。 | 問題 | 対処 | | --- | --- | | **MP4で読込エラーになる** | **VLCでMP3に変換してからアップロードすると安定**（データ構造起因のエラーを回避） | | 大きなファイルが通らない | モデルによりファイルサイズ上限が異なる（256MB / 512MB） | **「対応形式のはずなのに読み込めない」場合、コンテナ形式の問題であることがあります。**音声だけを取り出した形式に変換すると通ることが多くなります。 ## 一発出力を狙わない ワークフロー設計の結論です。 ``` 文字起こし → チャプター見出し付与 → 人間レビュー ``` **一発出力を狙わず、この反復のほうが安定します。** 文字起こしと構成付けを同時に指示すると、**構成を作るために内容が整理されてしまいます。**工程を分けることで、それぞれの目的を保てます。 ## 指示は「プロジェクト機能」に保存する 運用方法についての判断です。 **入力が毎回変わる用途では、固定のカスタムGPTを作るより、Geminiの「プロジェクト機能」に指示プロンプトを保存する方が運用しやすい。** 理由がもう1つあります。**履歴が貯まるとAI側がパターンを掴みやすくなるため、同一プロジェクトを継続して使うほうが有効です。** **毎回まっさらな状態から始めるより、これまでのやり取りが残っている場所で続けるほうが、指示が短くて済むようになります。** ## 編集はデスクトップ版で行う 将来の効率化方針として挙げられている点です。 **ブラウザ版より、デスクトップのコーディングツールで .md を原文保持しつつ上書き編集する方が、予測変換による劣化を回避できる。** 文字起こしの後工程で編集を加えるとき、**入力補助が働くと原文が意図せず変わることがあります。**テキストファイルとして扱えば、変更箇所を差分で確認できます。 ## よくある質問 ### なぜ勝手に要約されるのですか？ **指示がないと「読みやすく整える」方向に振れるためです。**「要約・構成案を作らない／忠実に文字起こしする」を明示的に指定する必要があります。 ### 話し言葉のまま残すには？ **「話し言葉維持・サンプル口調を継承」という条件を追加します。**あわせて、フィラーは除去するが内容は改変しない、というバランスを指示で固定します。 ### MP4が読み込めません **MP3に変換してからアップロードすると安定します。**データ構造に起因するエラーを回避できます。ファイルサイズ上限（モデルにより256MB / 512MB）にも注意してください。 ### 毎回同じ指示を書くのが面倒です **プロジェクト機能に指示プロンプトを保存し、同一プロジェクトを継続して使ってください。**履歴が貯まるとパターンを掴みやすくなり、指示が短くて済むようになります。 ## まとめ - 文字起こしでは**「要約しない・構成案を作らない」を明示する**ことが最重要 - **話し言葉を維持し、フィラーだけ除去する**という線引きを指示で固定する - MP4が読み込めない場合は**MP3に変換**すると安定する - **一発出力を狙わず「文字起こし → 見出し付与 → レビュー」の反復**にする - 指示は**プロジェクト機能に保存し、同一プロジェクトを継続**して使う - 後工程の編集は**デスクトップツールで原文保持しながら**行うと劣化を避けられる AIへの指示は、してほしいことより「してほしくないこと」のほうが効きます。特に文字起こしのような「原文を保つ」作業では、この指定が品質を決めます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の議事録・ナレッジ整備へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 同じ手順を2本目に適用したら何が変わったか｜並列エージェントで22章145,000字 - URL: https://ai-katsu.jp/articles/vercel-textbook - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-08T00:00:00+00:00 - Models: Claude Code - Tools: Vercel, Astro - Tasks: ナレッジ活用・RAG, 業務プロジェクト - Domain: 教育・研修 > 先行プロジェクトと同じ手順でVercel公式ドキュメントを教材化し、22章・約145,000字を数セッションで完成させました。差が出たのは並列実行のスループット。エージェントが承認待ちで止まる問題、robots.txtで「学習用途」と「参照用途」が区別される運用など、実務上の知見をまとめています。 1本目でうまくいった手順は、2本目でどこまで速くなるのか。この検証は、その確認でもありました。 前回と同じ手順でVercelの公式ドキュメントを教材化し、**22章・約145,000字を数セッションで完成**させています。差が出たのは**並列実行のスループット**でした。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 実施日 | 2026年5月8日 | | 位置づけ | 先行プロジェクト（Supabase教材）と**同じ業務手順**で行う派生プロジェクト | | スコープ | **コア機能フル + セキュリティ網羅 + AIインフラ網羅** | | 成果物 | **22章の.mdx／総文字数 約145,000字超**（章別平均6,500字） | | 一次ソース | 195件採用 / 30件除外候補に分類 | | 検証 | 0 errors / 0 warnings | | 状況 | 完了 | ## 結論：並列実行が最大の収穫 この検証で最も明確な改善点です。 **先行プロジェクトは逐次処理だったが、今回は3〜5並列で短縮効果が顕著だった。** 具体的には、**コア章8章を3セッション分の並列で消化**しています。同じ手順・同じテンプレートを使いながら、実行の仕方だけを変えた結果です。 **手順が固まっているからこそ並列化できます。**1本目で型を作り、2本目でスループットを上げる——この順番が効率的です。 ## 再現性の高い二段構成 この検証で確立したパターンです。 ``` 1. セキュリティ章で個別にプラン依存を書く（並列で分担） ↓ 2. 最後に統合マトリクスを自分で書く ``` **「セキュリティ章で個別にプラン依存を書く」「最後に統合マトリクスを自分で書く」の二段構成は再現性が高い**と評価しています。 個別の調査は分担できますが、**横断して比較する作業は分担できません。**集めた情報を1つの判断軸にまとめる工程は、全体を見ている人が担当する必要があります。 結果として、この統合章が**シリーズの中核**になっています。 ## ai-train=no という区別 この検証で見つかった、実務上重要な知見です。 **先行対象は `Allow: /` でAI学習も明示許可だったのに対し、今回の対象は `ai-train=no` でした。**ただし `ai-input=yes` / `search=yes` のため、参照目的の利用は可能です。 | 指定 | 意味 | | --- | --- | | `ai-input=yes` | AIへの入力としての利用は可 | | `search=yes` | 検索利用は可 | | **`ai-train=no`** | **学習用途での利用は不可** | **「学習用途と参照用途を区別する」robots.txtの運用が一般化しつつあります。** これは実務上の分岐点です。**同じ「クロールしてよいか」でも、何に使うかによって可否が変わります。**外部ドキュメントを扱う作業では、この区別を確認する手順が必要になります。 ## エージェントが承認待ちで止まる 並列実行で発生した問題です。 **初回のエージェントが「計画提示・承認待ち」で停止しました。** 対処は、**プロンプトに「即着手・確認不要・最後まで完遂」を明記して再投入**することでした。 改善策として、**エージェントプロンプトのデフォルトに「即着手・確認不要・Writeまで一気通貫」を含める**という運用に変更しています。 **並列で走らせている場合、1つが承認待ちで止まっていることに気づきにくくなります。**止まらない前提を明示しておく必要があります。 ## 大量のsitemapをどう扱うか もう1つ、規模による問題が出ました。 **sitemap.xmlがフラット形式で約1,000 URLあり、取得のサンプリング上限により一部のURLはナビゲーションからの推定採用になりました。** 改善策は2つです。 - **sitemapが大量の場合は、最初に対象ディレクトリ配下のみフィルタリングしてからカテゴリ分類する** - **推定採用したURLは、ソース一覧で個別にマークすると後段の追跡が楽になる** **「確実に取得したもの」と「推定で採用したもの」を区別して記録しておく**——後から検証する人にとって、この区別は重要です。 ## 調査で見えたプラットフォームの構造 教材化の過程で整理できた、実装時に効く知識です。 - **AIインフラの境界を4章で整理** — v0 / AI Gateway / MCP / Sandbox / Agent がそれぞれ何を担うのかを構造化 - **ドキュメントの所在が製品ごとに分かれている** — 独立サブドメインにあるもの、複数系統に分かれているものがある - **デフォルト設定の変更履歴** — 新規プロジェクトではデフォルト化されているが、既存プロジェクトは手動切替という機能がある - **特定バージョン未満で常時キャッシュミスになるバグ**など、組み合わせ依存の既知問題 - **マネージドサービスの移管** — 一部のデータストア製品が他社サービスへ移管され、自社継続は限られた製品のみ **まとめて読むと「今どの機能が主流で、何が移管・廃止されたか」が分かります。**断片的に情報を追っていると、既に移管済みの製品を前提に設計してしまうことがあります。 ## Changelogは網羅せず軸で意味づける 教材としての可読性を担保するための判断です。 **Changelogダイジェストを網羅ではなく5トピック軸で意味づけしました。** 変更履歴を全件並べても読めません。**「何が起きているか」の軸に整理し直すことで、読み物として成立します。** ## プラン依存表には見直し前提を書く 未解決課題として明記されている点です。 **プラン依存表は特定時点の理解で記述しており、プラン変更頻度を考えると四半期単位で見直しが必要です。** あわせて、変化の速い領域については**別ライフサイクルで管理する**方針も出ています。AI関連機能は半年〜1年単位で見直す前提です。 **教材の中で、更新頻度が違う部分を分けておく**——これは長く使う資料を作るときの設計判断になります。 ## コスト対効果 **22章・145,000字超の教材を数セッションで完成。手作業換算で数十時間相当のリサーチ・執筆を短縮**という評価です。 また、成果物は二次展開の素材にもなります。同じ内容を記事・講座・SNS投稿へ展開する際の元ソースとして再利用できます。 ## よくある質問 ### 1本目と2本目で何が変わりましたか？ **並列実行のスループットです。**先行プロジェクトは逐次処理でしたが、今回は3〜5並列で進め、短縮効果が顕著でした。手順とテンプレートは同じものを使っています。 ### すべてをAIに書かせているのですか？ **統合章は自分で書いています。**個別の調査は並列で分担できますが、横断して比較する作業は分担できません。この二段構成は再現性が高いと評価しています。 ### 並列実行で気をつけることは？ **エージェントが承認待ちで止まることです。**プロンプトに「即着手・確認不要・最後まで完遂」を明記しておく必要があります。並列で走らせていると、1つが止まっていることに気づきにくくなります。 ### 外部ドキュメントの利用可否はどう確認しますか？ **robots.txtで「学習用途」と「参照用途」が区別されている場合があります。**今回の対象は参照は可、学習は不可という指定でした。この区別を確認する手順を組み込んでおく必要があります。 ## まとめ - **手順が固まっているから並列化できる。**1本目で型を作り、2本目でスループットを上げる - **「個別章は並列で分担、統合章は自分で書く」の二段構成は再現性が高い** - **robots.txtは「学習用途」と「参照用途」を区別する運用が一般化しつつある** - 並列実行では**エージェントが承認待ちで止まる**。「即着手・確認不要・完遂まで」を明記する - 大量のsitemapは**対象ディレクトリでフィルタしてから分類**。推定採用したURLは個別にマークする - Changelogは**網羅せずトピック軸で意味づける**と読み物として成立する - 変化の速い領域は**別ライフサイクルで管理**し、更新前提を明記しておく 同じ作業を2回やると、1回目には見えなかった改善点が出てきます。手順を残しておくと、2回目以降の速度がまったく変わります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のナレッジ整備とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 音声のリアルタイム翻訳を実装する｜gpt-realtime-translateの落とし穴と本番構成 - URL: https://ai-katsu.jp/articles/openai-gpt-realtime-translate-api - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-08T00:00:00+00:00 - Models: OpenAI API, Claude Code - Tasks: 音声・翻訳・文字起こし, ツール検証 > speech-to-speech翻訳専用モデルでWebSocket実装を行い、翻訳音声・字幕・会話ログの保存まで確認しました。通常のRealtime APIとはイベント名もライフサイクルも異なり、Betaヘッダーがエラーの原因になります。$0.034/分のコスト感と、WebRTC + client secret方式への移行方針までまとめています。 音声のリアルタイム翻訳は、これまで**STT（文字起こし）→ 翻訳 → TTS（音声合成）**を自前で組み合わせて実現していました。各段階の遅延が積み上がるため、レイテンシが課題になります。 この検証では、音声翻訳専用モデル `gpt-realtime-translate` を使い、**speech-to-speechの翻訳アプリを実装して疎通まで確認**しました。**従量課金は $0.034/分**です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年5月8日 | | 対象 | OpenAI Realtime API（`gpt-realtime-translate`）／2026年5月7日GA | | 検証内容 | speech-to-speechリアルタイム翻訳のWebSocket実装、言語切替、字幕/会話ログ保存 | | 技術スタック | Next.js 16 + React 19 + Zustand / Custom Server / AudioWorklet | | 結果 | **実API接続・マイク入力・翻訳音声/字幕・会話ログ保存まで確認済み** | | コスト | **$0.034/分**（30分連続利用で約$1.02） | | 判定 | **条件付きで導入可**（★4/5） | ## 結論：通常のRealtime APIとは別物として扱う この検証で最も重要な学びです。 **Realtime Translationは、通常のRealtime APIとイベント名・ライフサイクルが違います。**通常のRealtime APIの知識だけで実装すると、誤った実装になります。 実際、初期実装は「WebSocket接続もボタン操作もマイク入力も動くが、**出力言語を変えてもスペイン語が返る**」という状態でした。 | 項目 | Realtime Translation | | --- | --- | | 接続先 | `/v1/realtime/translations?model=gpt-realtime-translate` | | **Betaヘッダー** | **GA APIなので `OpenAI-Beta: realtime=v1` を付けるとエラー** | | 出力言語の指定 | `session.audio.output.language` | | 音声入力イベント | `session.input_audio_buffer.append` | | 出力イベント | `session.output_audio.delta` / `session.output_transcript.delta` | | 入力書き起こし | デフォルト無効。`gpt-realtime-whisper` の設定が必要 | | `response.create` | **使わない**（モデルは「通訳」として動く） | **会話応答をしないという点が、通常のRealtime APIとの根本的な違いです。**連続ストリームを受け取り、翻訳して返し続けるだけの動作になります。 ## Betaヘッダーが原因だった 「出力言語が反映されない」問題の原因はこれでした。 **`OpenAI-Beta: realtime=v1` を付けたことで、GA Translation APIがベータRealtime APIとして扱われ、`session.audio` がunknown parameterになっていました。** | エラー | 原因 | 対処 | | --- | --- | --- | | `Translation sessions are only available on the GA API.` | Betaヘッダーを付けている | Translation endpointではBetaヘッダーを外す | | `Unknown parameter: 'session.audio'.` | ベータ互換モードで処理されている | Betaヘッダー削除、endpoint確認 | **「以前のバージョンで必要だったヘッダーが、GA後は逆にエラーの原因になる」**——APIの世代が変わるときによくある落とし穴です。 ## 「スペイン語が返る」の正しい確認方法 デバッグ時の観測知見として、これは押さえておく価値があります。 ``` session.created ... audio.output.language: "es" session.updated ... audio.output.language: "en" ``` **`session.created` の時点では初期値として `"es"` が返りますが、直後の `session.updated` でUI選択値に変わります。** つまり**「最初にcreatedでSpanishが見える」こと自体は問題ではありません。**確認すべきは `session.updated` の言語です。 **最初のログだけを見て原因を判断すると、正常な挙動をバグとして追いかけることになります。** ## 会話ログが残らない問題 もう1つの実装上の落とし穴です。 **会話ログが `*.done` イベント依存だったため、ライブ表示には出るがログに残らないケースがありました。** 対処は、**`*.done` だけでなく、停止/close時にlive transcriptをflushする設計**にすることです。 **ストリーミング処理では「完了イベントが必ず来るとは限らない」前提で保存設計を組む必要があります。** ## アーキテクチャ：なぜサーバproxyを挟むのか ``` ブラウザ/PC ↕ WebSocket Next.js custom server / Node.js ↕ WebSocket OpenAI Realtime Translation API ``` 理由は明確です。**ブラウザのWebSocketは任意のAuthorizationヘッダを付けられないため、サーバ側proxyを使う**必要があります。APIキーをブラウザに出さずに済みます。 この構成は**仕組みの理解とデバッグには向いています。**サーバログで `session.created` / `session.updated` / `error` を追えます。 ただし公開運用では課題があります。**自前サーバがクライアント接続とOpenAI接続の両方を長時間保持するため、WebSocketを保持できる実行環境が必要**になります。 ## 公開時のホスティング選定 | 候補 | 判定 | 理由 | | --- | --- | --- | | **Render Web Service** | **有力** | WebSocket対応。Node.js構成をそのまま載せやすい | | **Google Cloud Run** | **有力** | WebSocket対応。Docker化しやすい（timeoutと再接続設計は必要） | | Railway | 次点 | WebSocket対応。接続時間制限を前提に設計する | | VPS / Fly.io / EC2 | 可能 | 常駐プロセスを持てるため相性はよい | | **Serverless Functions** | **不向き** | **WebSocket常時接続を保持できない**（Streaming/SSEとWebSocketは別物） | | 共用レンタルサーバ | 不向き | 常駐Node.jsプロセス・リバースプロキシ管理が難しい | **Serverless FunctionsでWebSocketは保持できません。**StreamingやSSEに対応していることと、WebSocketを保持できることは別問題です。 使う場合は**フロントエンドだけをServerless環境に、Realtime中継は常駐可能な環境に分ける**構成になります。 ## 本番構成はWebRTC + client secret スマホ/ブラウザ向けの本番では、構成を変えるのが自然という判断です。 ``` スマホ/ブラウザ ↕ WebRTC OpenAI Realtime API 自前バックエンド → 短命client secretを発行するHTTP endpointのみ ``` **自前バックエンドが長時間WebSocketを中継しなくなる**のが最大の利点です。サーバはAPIキーを保持し、短命のclient secretを渡すだけになります。 | メリット | 注意点 | | --- | --- | | モバイルブラウザの音声通信に向いている | WebRTC実装へ作り替える必要がある | | 自前サーバの接続数/帯域負荷を抑えられる | セッション発行APIに認証・レート制限が必要 | | Serverless環境でも実装しやすい | モバイルのマイク許可・自動再生制限の検証が必要 | | レイテンシ面でも有利になりやすい | 翻訳ログの保存設計が別途必要 | ## コスト感 $0.034/分を1ドル150円で換算すると**約5.1円/分**です。 | 利用量 | API原価の目安 | 用途イメージ | | --- | --- | --- | | 10分/日 × 20営業日 | 約1,020円/月/人 | 旅行・軽い接客補助 | | 60分/日 × 20営業日 | 約6,120円/月/人 | 社内会議・営業同行レベル | | 4時間/日 × 20営業日 | 約24,480円/月/人 | 通訳端末/SaaSの法人価格帯と比較対象 | | 8時間/日 × 20営業日 | 約48,960円/月/人 | 常時通訳用途 | **使用時間によって、既存サービスとの損得が逆転します。**「APIのほうが安い」と一括りにはできません。 開発コストの見積もりも整理しています。 | 構成 | 初期開発 | 月額運用 | | --- | --- | --- | | 個人用PWA / 社内PoC | 数日〜2週間 | API費用 + 数千円のホスティング | | 社内向けスマホWebアプリ | 2〜6週間 | API費用 + 認証/ログ基盤 | | アプリストア配布 | 1〜3か月 | API費用 + 保守 | | 法人向けSaaS | 3〜6か月以上 | API費用 + 管理画面/監査/サポート | ## 対応言語の制約 - **入力は70以上の言語を自動検出** - **出力は13言語に限定**（Spanish, Portuguese, French, Japanese, Russian, Chinese, German, Korean, Hindi, Indonesian, Vietnamese, Italian, English） この検証では初期実装のUIに非対応言語（Arabic, Turkish等）が含まれており、**UIは公式対応の13言語に絞る**という修正を行っています。 **選べるのに動かない選択肢をUIに残すと、原因の切り分けが難しくなります。** ## 実運用で必要になる設計項目 PoCから本番へ進むために必要な項目です。 - HTTPS/WSS対応、APIキーのサーバ側管理、ユーザー認証 - **セッション単位の時間制限、利用量/課金ログ** - 切断時の再接続、ping/pong keepalive - **会話ログの保存/削除ポリシー** - **個人情報/機密情報を扱う場合の同意導線** - モバイルブラウザのバックグラウンド/画面ロック時の挙動確認 特にプライバシー面は重要です。**会議・通話・配信で利用する場合は、参加者に翻訳処理と外部API送信を明示する必要があります。**字幕/会話ログに個人情報が含まれる可能性もあります。 **医療・法律・金融など高リスク領域では、人間レビューや免責設計が必要です。** ## よくある質問 ### 従来のSTT→翻訳→TTS構成と何が違いますか？ **3つのAPIを組み合わせる必要がなく、各段階の遅延が積み上がりません。**実装量が減り、低レイテンシなライブ翻訳体験を短時間で試せます。一方でカスタムプロンプトやvoice選択といった細かい制御は限定的です。 ### 出力言語が反映されません **まず `OpenAI-Beta: realtime=v1` を付けていないか確認してください。**GA APIのため、これを付けるとベータ互換モードで処理され `session.audio` が無効になります。また `session.created` ではなく `session.updated` の言語を見てください。 ### Serverless環境にデプロイできますか？ **WebSocket proxy構成では不向きです。**Serverless FunctionsはWebSocketの常時接続を保持できません。RenderやCloud Runなど常駐可能な環境か、WebRTC + client secret方式への移行が必要です。 ### コストはどのくらいですか？ **$0.034/分（1ドル150円換算で約5.1円/分）です。**1日1時間・月20営業日で約6,120円/人という計算になります。使用時間によって既存サービスとの損得が変わります。 ## まとめ - **Realtime Translationは通常のRealtime APIと別物。**イベント名・ライフサイクルが異なり、通常APIの知識だけでは誤実装しやすい - **GA APIのため `OpenAI-Beta: realtime=v1` はエラーの原因になる** - 出力言語の確認は `session.created` ではなく**`session.updated`** を見る - 会話ログは**`*.done` 依存にせず、停止/close時にflushする** - **ブラウザのWebSocketはAuthorizationヘッダを付けられない**ためサーバproxyが必要。ただしServerless環境では保持できない - 本番は**WebRTC + client secret方式**に寄せると、サーバが長時間接続を持たずに済む - **$0.034/分。**使用時間によって既存サービスとの損得が逆転する - 入力70言語超・**出力は13言語に限定** 新しいAPIは、既存のAPIと似て見えても仕様が違うことがあります。公式のリファレンスでイベント名とライフサイクルを確認してから実装すると、原因不明の挙動に時間を取られずに済みます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の音声AI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 公式ドキュメント2,000ページを1日で教材化する｜スコープ設計とStep Ledger運用 - URL: https://ai-katsu.jp/articles/supabase-textbook - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-08T00:00:00+00:00 - Models: Claude Code - Tools: Supabase, Astro - Tasks: ナレッジ活用・RAG, 業務プロジェクト - Domain: 教育・研修 > Supabaseの公式ドキュメントを対象に、1日で20章の日本語教材にまとめた記録です。「全部読む」を目標にせずスコープを先に切ること、Step Ledgerをセッション横断のstate of truthにすること、横断視点の統合章はサブエージェントに任せないこと——再利用できる運用パターンをまとめています。 公式ドキュメントは読めば分かります。しかし**2,000ページを読み切って、必要なときに引ける形に整える**のは別の仕事です。 この検証では、Supabaseの公式ドキュメントを対象に、**1日で20章の日本語教材にまとめる**作業を行いました。中核となる成果物は**「安全に使える領域マップ」**です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 実施日 | 2026年5月8日（1日で完了） | | やりたかったこと | アップデート頻度の高いSupabaseについて「何がどこまで安全に使えるか」を整理し、判断軸として再利用できる状態にする | | スコープ | **コア概念フル + セキュリティ網羅 + 最新アップデート（副）**のハイブリッド（SDKリファレンスは目次レベル） | | 成果物 | **20章の.mdxファイル**（astro check で 0 errors / 0 warnings） | | 取得したURL数 | 総数**2,075件**（うち章別に取得した一次ソース約130件） | | 状況 | 完了 | ## 結論：スコープを先に切ると終わる 2,000ページを全部読むことはできません。この検証が1日で完了したのは、**最初にスコープを3つに切ったから**です。 | 領域 | 扱い | | --- | --- | | **コア概念** | フルで読む | | **セキュリティ** | 網羅する | | 最新アップデート | 副次的に押さえる | | SDKリファレンス | **目次レベルで押さえるのみ** | **「全部読む」を目標にすると終わりません。**何を深く読み、何を目次だけにするかを決めておくことが、完了できるかどうかを分けます。 SDKリファレンスを目次レベルに留めた判断が特に効いています。**リファレンスは必要になったときに引けばよく、事前に読み込む価値が低い**領域だからです。 ## Step Ledgerをセッション横断の「唯一の真実」にする この検証で最も再利用価値が高い運用パターンです。 **実行計画とStep Ledger（24ステップ）を1つのファイルに置き、セッション横断のstate of truthとして運用しました。** 効果は明確でした。**1セッション1〜2ステップでも進捗が一目で分かり、復帰コストがほぼゼロ**になります。 AIとの長時間作業では、コンテキストやレート上限の都合でセッションが切れます。**そのたびに「どこまでやったか」を思い出す作業が発生すると、実作業より確認のほうが時間を食います。**台帳を1つに集約しておくと、これが消えます。 ## サブエージェントの並列分担 作業自体はサブエージェントに分担させています。 **コア章8つを3並列バッチで進めることで、コンテキスト効率が良くなりました。** ただし全てを任せたわけではありません。**横断視点が要る章はサブエージェントに任せず、統合者が自分で書く**という方針をとっています。 実際、中核成果物である「安全に使える領域マップ」は最後の統合作業として自分で書いています。**個別の章を集めても、横断的な判断軸は出てきません。**ここは分担できない領域です。 ## 成果物：安全に使える領域マップ この教材の中核はこれです。 **セキュリティ章のマトリクスを「機能 × 安全度4段階 × プラン依存」で整理**しました。 技術選定で本当に知りたいのは、機能一覧ではありません。**「この機能はどのプランで、どこまで安全に使えるのか」**です。この形に整理しておくと、採用判断時にそのまま使えます。 ## つまずいた点 | 問題 | 原因 | 次回の対策 | | --- | --- | --- | | サブエージェントの出力を自分で書き戻す必要があった | **エージェントの種類によってWrite権限の有無が違う**ことを見落としていた | 発注前に権限の有無を確認する | | 公式docsの404が想定より多かった | URLを推測で渡していた | **sitemapから実URLを引いてから依頼する** | | 一部リファレンスが取得サイズ上限超で取れず | ページが大きすぎた | 「要追記」として明示的に残す | **「AIエージェントに任せたのに書き込まれていない」というトラブルは、権限設定が原因のことがあります。**実行前に確認しておく項目です。 404については、**URLを推測して渡すのではなく、sitemapで実在を確認してから渡す**という手順に改善しています。 ## 並列数は3〜4を上限に 運用上の実用的な知見です。 **並列バッチのバッチ数は3〜4を上限に固定するとレート制限に当たりません。** 並列数を増やせば速くなるわけではなく、レート制限に当たれば結局待つことになります。**安定して回る数を見つけて固定するほうが、全体としては速く終わります。** ## 公開先と非公開ワークスペースを分ける もう1つ、他プロジェクトにも踏襲したいという判断です。 | 区分 | 内容 | | --- | --- | | **公開用の正本** | 成果物の.mdxファイル（サイトのナレッジページとして公開） | | **非公開ワークスペース** | URL一覧・作業メモ | **「公開先と非公開ワークスペースを早い段階で分離する」**——作業途中のメモと成果物が混ざると、公開時に選別作業が発生します。最初から分けておくほうが確実です。 ## クロールの前にrobots.txtを確認する この検証では、作業開始前に**robots.txtを確認**しています。 今回の対象は `Allow: /` でAI学習・検索とも明示的に許可されていました。**教材化を前提としたクロールが問題なく行える状態**です。 **外部サイトを読み込む作業では、この確認を手順に組み込んでおくべきです。**サイトによって方針は異なります。 ## 調査で見えたSupabaseのトレンド 教材化の副産物として、プロダクトの方向性も整理できました。 - **「セキュリティ・バイ・デフォルト」への移行** — 匿名アクセスの廃止、Data APIのデフォルト非公開化、JWTの非対称署名 - **AI/エージェント対応の機能追加が急速** — Remote MCP Server、AI Assistant等 - **ブランチ運用の改善** — GitHub不要のブランチ運用が可能になり、本番ワークフローへの組み込み難度が下がった **まとめて読むと、個別のリリースノートでは見えない方向性が分かります。**これも教材化の価値の1つです。 ## 成果物の規模 | 項目 | 数値 | | --- | --- | | 公開ファイル数 | 20ファイル（概要 / コア8章 / セキュリティ5章 / アップデート2章 / リファレンス目次 / 改善ヒント / ソース） | | コア章のコード例 | 約50テーマ | | Launch Weekダイジェスト | 7イベント・49ハイライト | | Changelogダイジェスト | 43エントリ・6トレンド | | 検証 | `astro check` で 0 errors / 0 warnings（73ファイル） | 最後の行が重要です。**MDXの構文エラーを最終工程で機械的に検証**しています。大量に生成した成果物は、目視では確認しきれません。 ## 更新をどう保つか この種の教材には賞味期限があります。 - **アップデート頻度が高い領域は四半期に一度の更新運用が必要** - **ナレッジページに「最終確認日」表示を追加すると更新追跡しやすい** **作って終わりにすると、古い情報が残り続けます。**いつ時点の情報かを明示しておくことが、読む側にとっても書く側にとっても有用です。 ## よくある質問 ### 2,000ページを1日で読めるのですか？ **全部は読んでいません。**スコープを「コア概念フル + セキュリティ網羅 + 最新動向（副）」に切り、SDKリファレンスは目次レベルに留めています。章別に取得した一次ソースは約130件です。 ### サブエージェントに全部任せられますか？ **横断視点が必要な章は任せられません。**この検証でも、中核成果物である「安全に使える領域マップ」は最後に統合者が自分で書いています。 ### 並列数はどのくらいが適切ですか？ **3〜4を上限に固定するとレート制限に当たりません。**増やせば速くなるわけではなく、制限に当たれば結局待つことになります。 ### 外部ドキュメントを読み込む際の注意点は？ **作業前にrobots.txtを確認してください。**サイトによって、AI学習・検索利用の方針は異なります。 ## まとめ - **スコープを先に切ると終わる。**「全部読む」を目標にすると完了しない - **Step Ledgerをセッション横断のstate of truthにする**と、復帰コストがほぼゼロになる - 作業は並列分担できるが、**横断視点が要る統合章は自分で書く** - サブエージェント発注前に**Write権限の有無を確認する**。種類によって違う - URLは推測せず**sitemapで実在を確認してから渡す** - **並列数は3〜4で固定**するとレート制限に当たらない - **公開先と非公開ワークスペースは早い段階で分離する** - 大量生成した成果物は**最終工程で機械的に検証する** 技術ドキュメントの読み込みは、量が多いほど後回しになります。範囲を決めて分担すれば、1日で判断に使える形まで持っていけます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のナレッジ整備とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## スライド構成の「型」をAIに持たせる｜パターン辞書スキルと生成スキルの分業 - URL: https://ai-katsu.jp/articles/slide-design-patterns - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-06T00:00:00+00:00 - Models: Claude Code - Tasks: 資料作成・デザイン, ツール検証 > 生成ツールは形式を出せてもテーマ別の鉄則を持っていない、という課題に対し、スライド構成のパターン辞書を自作スキルにして生成は既存スキルへ委譲する設計を試しました。依頼ワード逆引きによる辞書の引き方、スキル発動率を上げるコツ、外部情報源を参照する際の著作権上の線引きまでまとめています。 スライド作成をAIに頼むと、形式は整っていても構成がその都度ブレます。原因は単純で、**生成ツールが「形式」は持っていても「テーマ別の鉄則」を持っていない**ためです。 この検証では、**スライド構成のパターン辞書を自作スキルとして持たせ、PPTX生成は既存スキルに委譲する**という設計を試しました。**スキル雛形の構築からPPTX出力まで約30分**で到達しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月6日〜（検証中） | | 対象 | slide-design-patterns（自作 Claude Code スキル）v0.1 | | やりたかったこと | スライド作成依頼に対し、テーマ別の鉄板構成を即座に提案できる状態にする | | 設計 | **スキル本体は構成提案のみを担当し、PPTX生成は既存スキルに委譲** | | 成果 | 「3ツール比較スライド5ページ」の依頼で**構成提案 → PPTX出力まで1〜2分**で完了 | | 判定 | **条件付きで導入可**／追加検証が必要 | > 参照元とした外部記事は個人研究用にローカル保管しており、本文・画像の再配布は行っていません。提案時には出典URLを併記する運用としています。 ## 結論：役割を分けるとスキルが安定する この設計の核心は分業です。 | 役割 | 担当 | | --- | --- | | **構成の提案**（どんな型で作るか） | パターン辞書スキル | | **PPTXの生成**（どう出力するか） | 既存の生成スキルへ委譲 | **1つのスキルに構成判断と出力処理の両方を持たせると、どちらも中途半端になります。**辞書を引いて型を決める工程と、それを形にする工程を分けることで、それぞれを独立して改善できます。 実際、「比較スライド作って」という依頼に対して**辞書 → 構成提案 → 生成スキル委譲のフローが想定通り動きました。** ## パターン辞書の構造 約50パターンを7カテゴリに分類しています。 - A: グラフ系 - B: 図解系 - C: レイアウト系 - D: 戦略フレーム系 - E: 配色 - F: 業界別リファレンス - G: メタ 重要なのは、辞書そのものより**引き方**です。 **「依頼ワード逆引き」表を用意し、ユーザーの依頼文から該当パターンへ即座に辿れるようにしています。**「比較スライド作って」「事業ポートフォリオ可視化」といった自然な依頼から、対応する型に到達できる形です。 **知識を持っていることと、必要なときに引けることは別です。**辞書は引く経路とセットで設計する必要があります。 ## スキルの発動率を上げるコツ 実装上の知見として、明確なものが出ています。 **スキルのdescriptionには「依頼キーワードを過剰なほど列挙」した方が発動率が安定します。** スキルは、書いてあっても呼ばれなければ意味がありません。**「どんな言い方で頼まれるか」を想定して並べておくことが、実用性を左右します。** ## 実際の出力 「Codex / Gemini CLI / Claude Code の3ツール比較スライドを5ページで」という依頼で検証しました。 | スライド | 内容 | | --- | --- | | 1 | タイトル | | 2 | エグゼクティブサマリー（用途で使い分ける3択） | | 3 | 6軸×3列の比較表 | | 4 | ユースケース別カード | | 5 | 選び方フローチャート | **5ページが破綻なく生成され、配色指定と強調記法によるプライマリカラー化も機能しました。**スキル発動からPPTX出力までは1〜2分です。 ただし、評価には条件が付いています。**初稿レベルなら即戦力。ただし配布前に事実確認（ライセンス・無料枠の数値）は必要。** **構成は任せられても、事実は任せられません。**比較表の数値は、必ず最新の公式情報で確認する工程が要ります。 ## データ取得で得られた知見 参照元の記事を収集する工程でも、実用的な発見がありました。 - **APIのバージョンが機能ごとに混在している** — 一部の機能はv1でないと404になる - **フィールドの命名規則が統一されていない** — 一方はcamelCase、もう一方はsnake\_caseという混在 - ページング判定の方法もエンドポイントによって異なる **非公式APIを使う場合、エンドポイントごとに仕様が揃っていない前提で組む必要があります。**「同じサービスのAPIだから同じ書き方でいける」とは限りません。 取得自体は、並列処理により**90件のメタ情報＋78本の本文＋1,631枚の画像を数分で完了**できました（画像ダウンロードはエラー0件）。 ## 著作権への配慮 この検証では、扱い方を明確に決めています。 - **本文・画像は個人研究用にローカル保管。再配布は行わない** - **データはgit管理外のディレクトリに隔離**（約186MBの画像を含む） - **提案時には出典URLを併記する運用** - 記事化にあたって画像を直接利用しない。**あくまで構成パターン抽出の参考用途** **外部の情報源を参照するスキルを作る場合、この線引きを最初に決めておく必要があります。**後から整理するのは困難です。 ## つまずいた点 | 症状 | 原因 | 対処 | | --- | --- | --- | | スキルからプロジェクトを参照できない | 相対symlinkの階層を誤った | 正しい階層に修正（移動時の追従手順もSKILL.mdに明記） | | `jq: parse error: Invalid numeric literal` | APIが404 HTMLを返している | エンドポイントを確認 | | `ModuleNotFoundError: No module named 'pptx'` | python3が別環境を指していた | 使用するpython3のパスを明示 | symlinkについては、**相対パスにしたことで「将来プロジェクトを移動する前提」の要件をクリア**できています。絶対パスにしていると、移動のたびに壊れます。 ## 残っている課題 - **画像をAIに視覚情報として渡せていない**（現状はパス案内のみ） - 配色テンプレと業界別リファレンスは、依頼ワードとの紐付けがまだ弱い - **複雑な依頼（大規模なピッチデック等）での耐久性は未検証** - 参照元のAPI仕様変更・記事削除で更新パイプラインが壊れるリスク 1つ目が本質的です。**現時点ではテキスト情報としてのパターンしか渡せておらず、実際の見た目をAIが参照できていません。**マルチモーダル入力を経由する方式が次の検証項目になります。 ## よくある質問 ### 既存のPPTX生成ツールと何が違いますか？ **テーマ別の「鉄板構成」を持っている点です。**生成ツールは形式を出せますが、どんな型で作るべきかの判断は持っていません。構成提案と生成を分業させることで、この差を埋めています。 ### どのくらい速くなりますか？ **比較スライド初稿の構成検討が30〜60分から数分になる見込みです**（要追加検証）。スキル発動からPPTX出力までは1〜2分でした。 ### そのまま配布できますか？ **できません。**構成は破綻なく生成されますが、比較表の数値などの事実関係は、配布前に最新の公式情報で再確認する必要があります。 ### 外部記事を参照する際の注意点は？ **本文・画像の再配布は行わず、構成パターンの抽出に限定することです。**データはgit管理外に隔離し、提案時には出典URLを併記する運用にしています。 ## まとめ - **構成提案と出力処理を分業する**と、スキルが安定する - 辞書は**「依頼ワード逆引き」とセットで設計する。**持っていることと引けることは別 - **スキルのdescriptionには依頼キーワードを過剰なほど列挙**すると発動率が安定する - **構成は任せられても事実は任せられない。**数値は配布前に必ず確認する - 非公式APIは**エンドポイントごとに仕様が揃っていない前提**で組む - 外部情報源を参照するスキルでは、**再配布しない・git管理外に隔離・出典を併記**の線引きを最初に決める - symlinkは**相対パスにすると移動に追従できる** AIに任せる範囲を「判断」と「作業」に分けると、それぞれ改善しやすくなります。どこまでを型として持たせるかが、出力の安定性を決めます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の資料作成業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIくさいスライドを卒業する｜画像生成にデザインカンプを作らせる分業設計 - URL: https://ai-katsu.jp/articles/gpt-image-2-slide-workflow - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-06T00:00:00+00:00 - Models: OpenAI API, OpenAI Codex - Tools: Figma - Tasks: 資料作成・デザイン, ツール検証 > PPTX生成エンジン単体ではAIらしいシンプルなデザインに寄る、という課題に対し、画像生成モデルに「視覚的な正解例」を先に作らせる分業を検討しました。最大の関門は画像から編集可能なPPTXへ戻す工程で、4ルートを固定した評価軸で比較する設計にしています。 AIにPowerPointを生成させると、たいてい**「AIらしいシンプルなデザイン」**に寄ります。情報密度が低く、罫線も注釈もない。コンサルティングファームの資料のような密度には届きません。 この検証では、その原因を**「PPTX生成エンジンだけで解こうとしていること」**と捉え、**画像生成モデルにデザインカンプを先に作らせる**という分業を検討しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月6日〜（検証中） | | やりたかったこと | 高密度・整った余白・罫線・注釈・チャート表現を持つスライドデザインに近づける | | 仮説 | **GPT Image 2を「デザインカンプ生成担当」、PowerPoint Agent Skillsを「PPTX実装担当」として分業する** | | この時点の成果 | 利用可否・連携ルートの調査整理（**実スライド生成PoCは未実施**） | | 状況 | 進行中 | > 本記事は調査・設計段階の記録です。実際のスライド生成と品質評価は未実施のため、成果物の評価は含みません。 ## 結論：画像生成は「完成品」ではなく「視覚的な正解例」を作らせる この検証で得た最も重要な整理です。 **GPT Image 2は「最終成果物」より「視覚的な正解例」を作らせる方が使いやすい。**そしてPowerPoint Agent Skillsには、**完成画像を読み取って再現する役割**を持たせます。 この分業が筋がよい理由は明確です。**画像生成モデルは視覚品質に強い一方、編集可能なPPTXオブジェクトを生成することは別問題**だからです。それぞれの得意領域に合わせて工程を分けます。 この発想自体は、LP制作で既に使われているものです。**「画像生成 → Figma / コード化 → 実装」という流れを、スライド制作に転用する**という仮説になります。 ## 最大の検証ポイント：画像から編集可能なPPTXへ戻せるか 分業の構想は立ちますが、そこに1つ難所があります。 **GPT Image 2で生成した画像は、そのままでは編集可能なPPTXではありません。**画像1枚を貼るだけなら見た目はよくても、あとからテキストや図形を細かく編集できません。 そこで、画像から編集可能なPPTXへ戻すルートを4つ比較する計画を立てています。 | ルート | 内容 | | --- | --- | | **画像1枚貼り** | 最短で見た目がよいが、編集性が弱い | | **Figma / Canva経由** | 取り込んでPPTX exportする | | **Vision解析 → 再構成** | 画像を解析し、テキストボックス・図形・罫線・チャート風オブジェクトへ再構成 | | **SVG中間表現 → ネイティブPPTX** | 画像を直接変換せず、中間表現を経由する | 評価軸も先に固定しています。**見た目の再現度／テキストの編集可能性／図形・矢印・罫線の編集可能性／フォント・色・余白の維持／PowerPointで開いたときの崩れ／修正指示への耐性／1枚あたりの工数／クライアント環境で使えるか。** **比較する前に評価軸を決めておくと、印象論での判断を避けられます。** ## ハイブリッド運用という現実解 全ページを編集可能にする必要はない、という整理も出ています。 **重要ページのみ画像1枚、本文ページはPPTXオブジェクト**——というハイブリッド構成です。 表紙・章扉・キースライドは見た目が効きます。一方、本文ページは修正が入る前提なので編集可能である必要があります。**用途に応じて作り方を変えるほうが、全体としての工数は下がります。** ## 日本語テキストの扱い 実務的な注意点です。 **日本語テキストを含む場合は、画像生成時の文字崩れを考慮し、最終テキストはPPTX側で差し替える前提がよい。** 画像生成モデルは日本語の文字を正確に描けないことがあります。**デザインの型は画像から取り、文字は後から載せ直す**という運用が安全です。 ## プロンプトは「雰囲気」だけでは足りない もう1つの実装上の知見です。 **「consulting slide」「Big Four style」のような雰囲気指定だけでなく、16:9、余白、罫線、凡例、脚注、ページ番号、出典、タイトルの粒度まで指定する必要があります。** 高密度な資料が高密度に見えるのは、要素が多いからではありません。**脚注・出典・凡例といった細部が揃っているからです。**これらを明示的に指定しないと、雰囲気だけ似た薄い出力になります。 ## ツール利用上の制約 調査で判明した点です。 - **Codex内蔵の画像生成ツールでは、モデル名を直接指定できない**（`gpt-image-2` を明示指定できない） - OpenAI API経由なら `gpt-image-2` を使った画像生成・編集の実装は可能 - 実運用では**ChatGPTのブラウザ画面から呼び出す方向が現実的**と判断 - Figma SlidesのPPTX exportには**フォント置換、インタラクションの静止化、グラデーションの変換などの制限**がある **「APIにモデルがある」ことと「使いたいツールから呼べる」ことは別です。**組み込み前に確認が必要になります。 ## PoCの進め方 まず**1枚スライド単位**で検証する方針です。対象は型が明確な3種類に絞っています。 - **比較表** - **2軸ポジショニングマップ** - **ロードマップ** 理由は**「型が明確なスライドで品質差を見やすいため」**です。自由度の高いスライドで比べると、何が効いたのか分からなくなります。 入力画像も1枚に固定して比較します。**変数を減らしてから比べる**という基本的な設計です。 ## クライアント環境という評価軸 この検証には、技術以外の観点も入っています。 **Figmaが使えないクライアント向けには、別のルートを現実解として試す**という判断です。制作側で最高精度が出るルートと、相手先で運用できるルートは別になります。 **ツール選定に「相手が使えるか」を評価軸として入れておくと、納品後に困りません。** ## よくある質問 ### なぜ画像生成を経由するのですか？ **PPTX生成エンジン単体では、AIらしいシンプルなデザインに寄りやすいためです。**画像生成モデルは視覚品質に強いので、先に「視覚的な正解例」を作らせ、それを実装工程で再現する分業が有効と考えています。 ### 生成した画像はそのまま使えますか？ **編集可能なPPTXにはなりません。**画像1枚を貼る運用は見た目はよいものの、テキストや図形の編集ができません。重要ページのみ画像、本文ページはPPTXオブジェクトというハイブリッドが現実的です。 ### 日本語の文字はきれいに出ますか？ **崩れることがあります。**最終テキストはPPTX側で編集可能テキストとして載せ直す前提にしておくのが安全です。 ### プロンプトのコツは？ **雰囲気の指定だけでは足りません。**16:9、余白、罫線、凡例、脚注、ページ番号、出典、タイトルの粒度まで具体的に指定する必要があります。 ## まとめ - AIらしいスライドになる原因は**PPTX生成エンジンだけで解こうとしていること** - 解決策は**画像生成モデルに「視覚的な正解例」を作らせ、実装は別工程に分ける**分業 - 最大の検証ポイントは**画像から編集可能なPPTXへ戻す工程**。4ルートを固定した評価軸で比較する - **重要ページのみ画像、本文ページはPPTXオブジェクト**というハイブリッドが現実解 - **日本語は画像側で崩れる前提。**最終テキストはPPTX側で載せ直す - プロンプトは**雰囲気ではなく、余白・罫線・凡例・脚注・出典まで具体的に指定する** - ツール選定には**「相手先の環境で使えるか」も評価軸に入れる** AIに任せる工程を分けると、それぞれの得意領域を活かせます。1つのツールで完結させようとすると、どこかで品質が頭打ちになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の資料作成業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AGENTS.mdは何をどう書かれているか｜OSS 25リポジトリ横断調査 - URL: https://ai-katsu.jp/articles/agents-md-research-overview - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-04T00:00:00+00:00 - Models: Claude Code, OpenAI Codex - Tools: GitHub - Tasks: 開発・エンジニアリング, ツール検証 > 主要OSS 25リポジトリのAI向け設定ファイルを横断調査しました。採用率はノーコード系6/10、大手系14/15。CLAUDE.mdが「AGENTS.mdへの薄いリダイレクト」に収束する動きや、失敗ログを動的に蓄積する思想、AI生成PRのレッドフラグリストという逆方向の記述までをまとめています。 「AGENTS.md ベストプラクティス」として流通しているテンプレートは、どれも似た内容です。しかし**実際のプロダクトのリポジトリを開くと、テンプレートには載っていない工夫が入っています。** この調査では、**主要OSS 25リポジトリを横断**し、公式ドキュメントには載らないが実コードベースでは採用されている設計を抽出しました。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査日 | 2026年5月4日 | | 調査対象 | **主要OSS 25リポジトリ**（ノーコード/ローコード/自動化系10 + 大手プロダクト15） | | 目的 | 汎用テンプレートを超えて、**実プロダクトで採用されている応用・差別化された設計観点**を抽出する | | 構成 | 本記事（全体像）＋深掘り3本 | ## 結論：採用率にはっきり差が出た **ノーコード系 6/10、大手系 14/15。AIネイティブ製品ほど深い実装を持つ傾向**が確認できました。 「AI向け設定ファイルを置いているか」だけでなく、**どこまで作り込んでいるかに大きな幅があります。**1行のリダイレクトだけのものから、独自のプラグインマーケットプレイスを構築しているものまで存在します。 ## トレンド①：AGENTS.md が事実上の業界標準に収束 **OpenAI Codex起源で、現在はLinux Foundation配下のAgentic AI Foundationが管理する規格**です。 複数のAIエージェントが共通で参照する**中立フォーマット**として浮上しました。特定のツールに紐づかない点が、標準化を後押ししています。 ## トレンド②：CLAUDE.md は「薄いリダイレクト」に収束 これが最も実務的な発見です。 複数のリポジトリで、**CLAUDE.md が極端に小さいファイルになっています。** - あるリポジトリの `.claude/CLAUDE.md` は**「See agents.md in the repository root」の1行** - 別のリポジトリのCLAUDE.mdは**280バイト** - **9バイトのファイル**を置いているものもある **メンテナンスコストをAGENTS.mdに集約する戦略**です。同じ内容を2つのファイルで維持すると、必ずズレます。 **ツールごとにファイルを用意する必要があっても、実体は1つに寄せる**——これは自社で運用する際にもそのまま使える判断です。 ## トレンド③：`.agents/` ディレクトリの出現 `.claude/` や `.cursor/` に加えて、**`.agents/` を設置するリポジトリが現れています。** あるリポジトリでは `.agents/features/` に**46件**のファイル、加えて `.agents/rules/` と `.agents/skills/` を配置しています。 **ツール非依存の汎用エージェント設定の標準化が始まっている**という動きです。 ## トレンド④：ignoreファイルの多元化 **`.claudeignore` / `.agentignore` / `.cursorignore` を並列管理**しているリポジトリがあります。 **エージェント別に除外設定を分離する運用**です。ツールによって読ませたくない範囲が違う、という実態を反映しています。 ## トレンド⑤：失敗ログの動的蓄積 設計思想として最も注目すべき変化です。 **静的なベストプラクティスではなく、経験則ライブラリとして運用する**という考え方が広がっています。 - あるリポジトリは `.cursor/lessons.md` に**ユーザーが訂正するたびに記録** - 別のリポジトリは `.clinerules/` に**手動介入が必要だった時に書く** **「いつ書くか」のポリシーが決まっている**点が重要です。漫然と追記するのではなく、トリガーが定義されています。 ## トレンド⑥：AI生成コードへの防衛的記述 逆説的な動きです。 あるリポジトリのコードレビュー用インストラクションには、**「AI生成PRのレッドフラグリスト」**が含まれています。 - fabricated diffs（実在しない差分） - unrelated file changes（無関係なファイル変更） - empty descriptions（空の説明） **エージェント向けのガイドが、エージェントの産物を人間がレビューするための指針も兼ねるという二重構造**になっています。 AIに書かせることと、AIが書いたものを疑うことが、同じファイルに同居しています。 ## 採用ファイルの分布 調査では、リポジトリごとにどの種別のファイルを採用しているかをマトリクスで整理しました。 | ファイル種別 | 位置づけ | | --- | --- | | **AGENTS.md** | 中立フォーマット。階層構造を持つケースも | | **CLAUDE.md** | 薄いリダイレクトに収束する傾向 | | `.claude/` | プラグイン・hooks等の実装 | | `.cursor/` | rules・lessons | | copilot-instructions | レビュー特化で使われるケースあり | | **独自ディレクトリ** | `.agents/`、`microagents/`、`ai_policy.md` など | ## 深掘り3本の内容 | 記事 | 扱う内容 | | --- | --- | | **プラグインアーキテクチャ** | 独自プラグインマーケットプレイスの構築、14スキルの分類、エージェント役割分離、フックによるテレメトリ送信 | | **失敗ログ蓄積パターン** | 「いつ書くか」のポリシー、セルフインプルーブメントループ、tribal knowledgeの動的蓄積 | | **セキュリティ・境界設計** | アーキテクチャ境界、エディション境界、SSRF対策、物理ブロック、AI自律性のガバナンス | ## この調査の使い方 自社でAIエージェント向けの設定を整備する際、次の順で参考にできます。 1. **まずAGENTS.mdに集約する**——ツール別ファイルは薄いリダイレクトで済ませる 2. **「いつ書くか」のトリガーを決める**——訂正されたとき、手動介入が必要だったとき 3. **踏み越えてはいけない境界を明示する**——AIは最短経路を取ろうとする 4. **AI生成物をレビューする側の指針も同じ場所に書く** ## よくある質問 ### AGENTS.md と CLAUDE.md はどちらを書くべきですか？ **AGENTS.mdに集約し、CLAUDE.mdは薄いリダイレクトにするのが観測されたトレンドです。**実際に「See agents.md in the repository root」の1行だけ、あるいは数百バイトのファイルを置くリポジトリが複数あります。 ### なぜ `.agents/` ディレクトリが増えているのですか？ **ツール非依存の汎用エージェント設定を標準化する動きです。**`.claude/` や `.cursor/` といったツール固有ディレクトリとは別に設置されています。 ### 設定ファイルは書いたら終わりですか？ **動的に蓄積する運用が広がっています。**ユーザーが訂正したとき、手動介入が必要だったときに追記する——というトリガーを決めて運用するパターンが観測されました。 ## まとめ - 採用率は**ノーコード系6/10、大手系14/15**。AIネイティブ製品ほど実装が深い - **AGENTS.md が中立フォーマットとして業界標準に収束** - **CLAUDE.md は薄いリダイレクトに収束。**メンテコストを1箇所に集約する戦略 - **`.agents/` の出現**——ツール非依存の設定標準化が始まっている - **ignoreファイルの多元化**——エージェント別に除外範囲を分ける運用 - **失敗ログを動的に蓄積する思想**が広がっている。「いつ書くか」のトリガーが鍵 - **AI生成PRのレッドフラグリスト**という逆方向の記述も登場している 設定ファイルの書き方は、テンプレートより実プロダクトの運用に学ぶほうが得るものが多くなります。何を書くかより、どう更新し続けるかに差が出ています。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## リポジトリ内に独自プラグイン市場を作る｜14スキルとエージェント分業の設計 - URL: https://ai-katsu.jp/articles/agents-md-plugin-architecture - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-04T00:00:00+00:00 - Models: Claude Code - Tools: n8n, MCP - Tasks: 開発・エンジニアリング, ツール検証 > 調査で最も先進的だったAI設定の実装を分解しました。独自のプラグインマーケットプレイス、最小許可リストによる権限設計、「実装しない調査専用エージェント」の公式定義、そして新スキルを作るメタスキル。設定が成長し続ける構造をまとめています。 AIエージェント向けの設定というと、1枚のMarkdownを置くイメージがあります。しかし調査した中で最も先進的だった事例は、**リポジトリ内に独自のプラグインマーケットプレイスを構築**していました。 この記事では、その体系を**設定・エージェント定義・スキル分類・テレメトリ・階層構造**の5観点から分解します。 > 本記事はOSS横断調査シリーズの深掘り記事です。全体像は「AGENTS.md / CLAUDE.md 実装事例 横断調査」をご覧ください。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査日 | 2026年5月4日 | | 対象 | OSSノーコードワークフロービルダーのAIエージェント設定 | | 特徴 | **リポジトリ同梱の独自プラグインマーケットプレイス**／2エージェント／**14スキル**／テレメトリ計測 | ## 結論：スキルが自己増殖する仕組みまで作られている この事例で最も示唆的なのは、**`create-skill`（新スキルを作るスキル）というメタスキルが存在する**点です。 **組織として継続的にスキルを増やす仕組みがツール化されており、エージェント設定が成長し続ける構造**になっています。 設定ファイルを「書いて終わり」にせず、増やす手順まで含めて設計されています。 ## 独自マーケットプレイスという発想 設定ファイルには `extraKnownMarketplaces` という指定があります。 ``` "extraKnownMarketplaces": { "n8n": {"source": {"source": "directory", "path": "./.claude/plugins/n8n"}} }, "enabledPlugins": {"n8n@n8n": true} ``` これは比較的新しい機能で、**社内・プロジェクト内に独自のプラグインレジストリを定義できます。** この事例では**「リポジトリ同梱の社内マーケットプレイス」**として活用し、すべての社内スキル・エージェント・コマンドに専用のネームスペースを付与しています。 **個人やサードパーティが作るスキルとの命名衝突を防ぐ設計です。**スキルが増えるほど、この分離が効いてきます。 ## 権限は最小許可リストで組む 設定の `permissions.allow` に含まれるのは、次のような操作だけです。 - **読み取り系のgitコマンド**（log / show / grep / ls） - **テスト系のコマンド**（build / lint / test / typecheck） - **計画ファイルディレクトリへの書き込み** **破壊的操作（削除・強制プッシュ・リセット等）は一切含まれていません。** 許可リスト方式は、**「危険なものを禁止する」のではなく「安全なものだけ通す」**という発想です。想定外の操作が自動的に弾かれます。 ## エージェントの役割分離 2つのエージェントが明確に分離されています。**「エージェントの分業」をOSSで公式化した数少ない例**です。 | | developer（青） | issue-triager（赤） | | --- | --- | --- | | 役割 | フルスタック開発 | **調査のみ・実装は行わない** | | 範囲 | フロントエンド／バックエンド／ワークフローエンジン | severity分類（CRITICAL / HIGH / MEDIUM / LOW） | | 制約 | 5ステップのワークフロー（チケット取得 → 影響範囲特定 → 実装 → テスト追加 → PR作成） | **チケットへの直接書き込み禁止**（人間が確認してから書く） | **「実装しないエージェント」を公式に定義することで、調査と実装の責任を分離し、エージェント間の暗黙の越権を構造的に防いでいます。** 細部ですが、**色（青／赤）による視覚識別**も設計されています。UI上で「いま誰が動いているか」を即座に把握させるためです。 ## 14スキルを機能で分類する ### コントリビューションフロー系 PR作成スキルには具体的な制約が入っています。 - **タイトルはConventional Commitsの正規表現で検証** - **セキュリティ修正は中立的タイトル必須** - `(no-changelog)` サフィックスでリリースノートから除外 ### 実装系 | スキル | 注目点 | | --- | --- | | OAuth追加 | **10ステップの手順**。カスタムスコープUI、ゲートウェイAPI型にも対応 | | エンドポイント保護 | 認証スコープの標準マッピング、**リグレッションテストのパターン**まで規定 | ### 調査・診断系 **バグ再現スキルが特徴的です。実装はせず、再現テストだけを作ります。** - 結果を**CONFIRMED / LIKELY / UNCONFIRMED / SKIPPED / ALREADY\_FIXED の5段階**で分類 - **「本物のクレデンシャル必須」「レースコンディション」「クラウド固有インフラ」はハードベイルアウト**（諦める条件を明示） **「できない条件」を先に定義している点が実用的です。**AIは無理にでも進めようとするため、撤退条件が必要になります。 もう1つ、**動画のトランスクリプトを取得するスキル**も用意されています。**人間が動画で共有した仕様をAIに読ませる経路**——非テキスト情報をエージェントに渡す設計として注目できます。 ### 仕様・規約系 - **仕様駆動開発スキル**——仕様ディレクトリを正本として、実装との乖離を**Aligned / Drift / Gaps の3分類**で差分報告 - **デザインシステムスキル**——**Semantic tokens → Primitives → Hard-coded values の優先順位**を定義し、非推奨コンポーネントやレガシートークンを強く警告 ### メタ系 前述の `create-skill` に加え、MCPサーバーのセットアップスキルがあります。 ## スキルの粒度 調査から見えた重要な観察です。 **スキル粒度は「ドメイン特化のレシピ」レベルです。汎用スキルではなく、そのコードベース固有の知識を埋め込んだ手順書として機能しています。** 汎用的な「良いコードの書き方」ではなく、「このリポジトリでOAuthを追加するときの10ステップ」が書かれています。 ## どのスキルが使われているかを計測する 運用面で興味深い実装です。 **フックが、スキル実行のたびに計測スクリプトを非同期実行します。**ユーザー識別子をハッシュ化したうえで送信する仕組みです。 - **OSS内部で「どのスキルが使われているか」を定量計測する**——エージェント設計を改善するフィードバックループ - **計測を実行しない選択肢も提供されており、プライバシー設計が明示的** - **非同期実行＋タイムアウト付き**で、送信失敗が開発を妨げない **作ったスキルが実際に使われているかを測る仕組みは、他ではあまり見ません。**使われていないスキルを見つけられます。 ## コマンドは委譲のラッパー コマンドは、エージェント呼び出しを簡略化する役割を担っています。 - **計画コマンド**——チケットIDを引数に取り、計画ファイルを生成。出力構造は**タイトル・リンク・サマリ・実装計画・テスト戦略・リスクの6セクション**に固定 - **トリアージコマンド**——調査専用エージェントへの委譲ラッパー 出力構造を固定しておくと、**誰が実行しても同じ形式の計画が出てきます。** ## モノレポでは階層化する **サブパッケージごとにAGENTS.mdを配置し、グローバル指示と局所的指示を分離**しています。 たとえばフロントエンドのパッケージでは、デザインシステム関連の変更時に特定のスキルを使うことを必須化しています。 **ルートに全部書くと肥大化し、関係ない指示まで読ませることになります。**階層化すればコンテキストを節約できます。 ## よくある質問 ### スキルはどう増やしていくのですか？ **新スキルを作るためのメタスキルが用意されています。**組織として継続的にスキルを増やす仕組みがツール化されており、設定が成長し続ける構造になっています。 ### 権限設定はどう組むべきですか？ **最小許可リスト方式です。**読み取り系gitコマンド、テスト系コマンド、計画ファイルへの書き込みだけを許可し、破壊的操作は一切含めない構成が観測されました。 ### エージェントは1つでよいですか？ **役割で分離する例があります。**特に「実装しない・調査だけする」エージェントを公式に定義すると、責任範囲が明確になり暗黙の越権を防げます。 ### スキルは汎用的に書くべきですか？ **ドメイン特化のレシピとして書かれています。**汎用的な指針ではなく、そのコードベース固有の知識を埋め込んだ手順書として機能しています。 ## まとめ - **リポジトリ同梱の独自プラグインマーケットプレイス**という構成。ネームスペースで命名衝突を防ぐ - 権限は**最小許可リスト**。危険なものを禁止するのではなく安全なものだけ通す - **「実装しないエージェント」を公式定義**して、調査と実装の責任を分離 - バグ再現スキルには**5段階の結果分類と撤退条件**が定義されている - スキル粒度は**汎用指針ではなくドメイン特化のレシピ** - **スキル利用状況を計測するフィードバックループ**を持つ（プライバシー配慮つき） - コマンドは**出力構造を固定した委譲ラッパー** - モノレポは**サブパッケージごとに設定を階層化**してコンテキストを節約 - **新スキルを作るメタスキル**により、設定が成長し続ける AIエージェントの設定は、1枚のドキュメントで完結させる必要はありません。増やす仕組みと使われ方を測る仕組みまで含めると、運用しながら育てられます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AI設定ファイルは書いたら終わりではない｜失敗ログを蓄積する3つの実装 - URL: https://ai-katsu.jp/articles/agents-md-failure-log - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-04T00:00:00+00:00 - Models: Claude Code, OpenAI API - Tasks: 開発・エンジニアリング, ツール検証 > AI向け設定には静的なベストプラクティス集と動的な経験則ライブラリの2つの思想があります。後者を採用する3つのOSSを比較し、「いつ書くか」のトリガー定義、ユーザー訂正をAI自身が恒久知識に変換するループ、導入判断のフレームまでまとめています。 AIエージェント向けの設定ファイルには、2つの設計思想があります。**静的なベストプラクティス集**として書くか、**動的に蓄積される経験則ライブラリ**として運用するか。 この調査では、後者を採用している3つのOSSプロジェクトを比較し、**長期運用を前提とした設計思想**を抽出しました。 > 本記事はOSS横断調査シリーズの深掘り記事です。全体像は「AGENTS.md / CLAUDE.md 実装事例 横断調査」をご覧ください。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査日 | 2026年5月4日 | | 対象 | 失敗ログを動的に蓄積している3プロジェクト | | 着目点 | **「いつ書くか」のポリシー**／セルフインプルーブメントループ／tribal knowledgeの蓄積設計 | ## 結論：「いつ書くか」を決めないと肥大化する 動的蓄積の最大の利点は、**ドキュメントが実際に発生した事象に裏打ちされていること**です。エージェントが「過去に同じ罠に落ちた事例」を参照できるため、再発防止の精度が高くなります。 しかし同時に、書き手側に**「いつ書くか」の判断基準**が要求されます。ここを決めていないと、ただ膨れ上がるだけのファイルになります。 | 観点 | 静的ベストプラクティス | 動的経験則ライブラリ | | --- | --- | --- | | 記述タイミング | 設計時に一括記述 | **失敗・訂正のたびに追記** | | 主たる目的 | 「あるべき姿」の規範化 | **「実際に起きたこと」の記録** | | **肥大化リスク** | 高（網羅的に書きがち） | **低（更新基準で制御）** | | **陳腐化リスク** | 高（コードと乖離） | **低（実体験に紐づく）** | ## 事例①：ユーザー訂正を恒久知識に変換するループ あるプロジェクトでは、エージェントの行動規範として次のループが定義されています。 > "After user corrections, document patterns in `.cursor/lessons.md`. Incrementally refine rules to prevent recurring mistakes." つまり**「ユーザーから訂正を受けたら、そのパターンを記録し、ルールを継続的に改善する」**という自己改善ループを、公式ワークフローとして組み込んでいます。 ### 実際に蓄積されている内容 実障害が時系列で記録されています。代表例は次のようなものです。 - **フレームワークのアップグレードで `@Override` がサイレント失敗**——バージョン違いによりインターフェース変更が無告知で発生し、`@Override` が消えてもコンパイルが通る - **特定のスクリーンリーダーで挙動が崩れるアクセシビリティ問題** - **並列テストの共有setupパターン**——複数テスト間でのリソース競合 **これらは公式ドキュメントには載りませんが、実際にエージェントが踏んだ地雷の記録として、後続のセッションに渡されます。** ### 設計上の要点 - **ユーザー訂正をエージェント自身が恒久知識に変換する経路を公式化している**——通常はメンテナが手動で書くtribal knowledgeを、AIが記録する - **ファイル名が「lessons」（教訓集）であってベストプラクティス集ではない**のは意図的。**失敗から学んだ事項に限定することで、エントロピーの増加を防いでいる** - 別ファイルには「複雑な問題にはサブエージェントを活用して研究・探索・並列分析を委譲」というエージェント分担戦略も明示 ## 事例②：「いつ書くか」をルール化する 別のプロジェクトは、入口ファイルからドメイン別ファイル（general / network / cli 等）を参照する分散構造をとっています。 特徴的なのは、**「このファイルをいつ更新するか」の基準そのものを明示している**点です。 - **手動介入が必要だった時** - **複数試行が必要だった時** - **gotcha（落とし穴）に当たった時** - **経験則として「次回も役立つ」と感じた時** **これは「ドキュメントを書くタイミング」をエージェント自身に判断させるためのメタルールです。** ### 実際に蓄積されている内容 - **3箇所同時更新のゴッチャ**——1つの定義変更には3ファイルの同期更新が必要。さもないとAPI側で**サイレントリセット**が発生する - キャッシュタイミングの例外ケース——通常のフローから外れる条件 - 変換マッピングのような**「動かしてみないとわからない」性質の知識** ### 設計上の要点 - **「いつ書くか」の基準をルール化することで、肥大化を抑制しつつ価値の高い知識だけが残る** - **「動かしたら詰まった事項」だけを記録**することで、ファイルが**「最新の地雷マップ」**として機能する - **ドメイン分割によりコンテキスト効率が高い**——エージェントが関連ファイルだけを読めばよい ## 事例③：独立ファイルを切らない軽量な方式 3つ目は、設定ファイル内に**「Operational Insights」セクション**として運用知見を蓄積する方式です。 注目すべきはセクション名です。 **「Best Practices」ではなく「Operational Insights（運用上の洞察）」になっています。**これは**「あるべき姿」ではなく「実際に起きたこと」を記録する意図**の表れです。 独立ファイルを切らず同居させる軽量な実装で、**リポジトリ規模に応じた選択肢**として有効です。 ## 共通する4つの設計パターン ### パターンA：ベストプラクティスと経験則を別ファイルに分離する **混在させると更新責任が曖昧になります。**静的指針と動的蓄積を完全に分けるのが明快です。 ### パターンB：「いつ書くか」を明文化する **追記の判断基準そのものをドキュメント化します。**これにより肥大化と陳腐化を同時に抑制できます。 ### パターンC：失敗の主体を「エージェント」と認識する 従来の運用手順書は人間のオペレーター向けでした。しかしAI設定ファイルでは**エージェントが踏んだ地雷**を記録します。 このシフトにより、**エージェント特有のミス（訓練データに無いAPI変更へのサイレント失敗など）が記録対象になります。** ### パターンD：エージェント自身に記録を委ねる **エージェントの行動ループに記録を組み込みます。**これによりメンテナの手動更新負荷を下げられます。 ## 導入すべきかの判断フレーム | 条件 | 動的ライブラリの有効性 | | --- | --- | | **エージェントセッションが繰り返し走る** | **高** | | **コードベースが古く、tribal knowledgeが多い** | **高** | | **公式ドキュメントが追いつかないペースで開発される** | **高** | | エージェントセッションが1回限り | 低 | | 規範的ガイドだけで十分な小規模プロジェクト | 低 | **繰り返し使うかどうかが分岐点です。**1回限りの作業では、蓄積のコストが回収できません。 ## よくある質問 ### ベストプラクティス集を書くのではだめですか？ **併存させる構成が現実的です。**ただし混在させると更新責任が曖昧になるため、静的指針と動的な失敗ログはファイルを分けるのが明快です。 ### ファイルが肥大化しませんか？ **「いつ書くか」の基準を明文化することで抑制できます。**手動介入が必要だった時、複数試行が必要だった時、落とし穴に当たった時——といったトリガーを定義します。 ### 誰が書くのですか？ **エージェント自身に記録させる設計があります。**ユーザーから訂正を受けたらパターンを記録する、という行動ループを公式ワークフローに組み込む例が観測されました。 ### どんなプロジェクトに向いていますか？ **エージェントセッションが繰り返し走り、tribal knowledgeが多く、ドキュメントが開発ペースに追いつかないプロジェクトです。**1回限りの作業では効果が薄くなります。 ## まとめ - 設定ファイルには**静的なベストプラクティス集と動的な経験則ライブラリ**の2つの思想がある - 動的蓄積の利点は**実際に起きた事象に裏打ちされていること**。再発防止の精度が高い - **「いつ書くか」を決めないと肥大化する。**トリガーの明文化が鍵 - ファイル名を**「lessons」「Operational Insights」にする**ことで、記録対象を失敗に限定できる - **ベストプラクティスと経験則はファイルを分ける**——混在は更新責任を曖昧にする - **記録対象は「エージェントが踏んだ地雷」。**人間向け運用手順書とは主体が違う - **繰り返し使うかどうか**が導入判断の分岐点 AIに渡す情報は、書いた時点で完成するものではありません。運用しながら更新する経路を設計に含めておくと、使うほど精度が上がります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIが踏み越えてはいけない線をどう書くか｜境界設計の5分類 - URL: https://ai-katsu.jp/articles/agents-md-security-boundary - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-04T00:00:00+00:00 - Models: Claude Code - Tools: Dify, n8n - Tasks: 開発・エンジニアリング, ツール検証 > AIは「動くコード」のために最短経路を取ろうとします。6つのOSSを題材に、踏み越えてはいけない境界の表現方法をアーキテクチャ・エディション・入出力・自律性・コミュニケーションの5つに分類しました。「絶対に〜しない」という否定形が効く理由も解説します。 AIエージェントは指示が曖昧だと暴走しがちで、しかも**「動くコード」を作るために最短経路を取ろうとする**傾向があります。 そのためコードベース側で**「ここから先は絶対に踏み越えるな」**という境界を明示する記述が、急速に発達しています。この調査では6つのOSSを題材に、その表現方法を**5つに分類**しました。 > 本記事はOSS横断調査シリーズの深掘り記事です。全体像は「AGENTS.md / CLAUDE.md 実装事例 横断調査」をご覧ください。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査日 | 2026年5月4日 | | 対象 | 境界設計を明示している6つのOSSプロジェクト | | 分類 | **アーキテクチャ／エディション／入出力／自律性／コミュニケーション**の5境界 | ## 結論：「絶対に〜しない」という否定形が効く 調査全体を通じて見えた表現上の要点です。 **「絶対に〜しない」という否定形での宣言が効果的で、肯定形（「〜する」）よりも境界として機能します。** もう1つ重要な点があります。 **アーキテクチャ境界はコードを読むだけでは見えません。**「あえて書かない」という設計判断は、コード上に痕跡が残らないためです。だからこそ、AI向け設定ファイルで明示する意義が大きくなります。 ## 分類A：アーキテクチャ境界 「このコンポーネントはこの責任を絶対に持たない」という設計上の不変条件を伝えます。 あるワークフロー基盤のAGENTS.mdには、次の記述があります。 > **Scheduler は絶対にユーザーコードを実行しない。** これはセキュリティモデルそのものです。**SchedulerがDAGファイルから任意コードを実行すると、Workerとの権限境界が壊れます。** 別のフレームワークでは、**Dead Code Eliminationの境界**や**エッジランタイムとNodeランタイムの境界**、特定の環境変数を使ったときの落とし穴が明示されています。 **AIは「動かすために」境界を踏み越えがちです。**明示しておかないとリスクになります。 ## 分類B：エディション境界 オープンコア型のビジネスモデルでは、Community EditionとEnterprise Editionでコードが分離されます。 > **CEコードに `src/app/ee/` を絶対 import しない** ここが重要な指摘です。**エディション境界はビジネス上の理由（ライセンス・課金）で存在するため、技術的には自由に行き来できてしまいます。** **AI視点では「使えるなら使う」になりがちで、明示的な禁止指示が必要です。**技術的な制約がないものは、書かなければ守られません。 理想的には、違反検出のためのLintルールやCIチェックも併設します。 ## 分類C：入出力境界（SSRF・インジェクション対策） 脆弱性に直結する領域です。 ### 標準ライブラリを使わせない あるプロジェクトでは、サーバーパッケージからの外部HTTPに**標準のHTTPクライアントではなく独自ラッパーを使うよう指示**しています。 このラッパーは**プライベートIP（10.x.x.x、169.254.x.x、127.x.x.x 等）へのリクエストをブロックするSSRF対策**を含みます。 ### マルチテナントのスコープ強制 > **ORM操作では必ず `tenant_id` でクエリをスコープする / 生SQLの使用禁止** マルチテナントSaaSで、**AIが「便利だから」と他テナントのデータに横断クエリを書いてしまうリスク**への対策です。 ### 要点 **AIは標準APIを使いがちです。「標準より独自ラッパーを使え」という指示は明示的に書く必要があります。** そして**規約の遵守はCIレベルで強制する**のが望ましい領域です。ドキュメントに書くだけでは守られません。 ## 分類D：自律性境界（ガバナンス） AIエージェントの自律的な行動範囲を制限し、**「人間の介在を必須とする操作」**を明文化します。 ### 完全自律の禁止 あるプロジェクトは、技術仕様とは**独立したガバナンスポリシーファイル**を設置しています。 > ポリシーは、人間の関与なしに「完全自律エージェント」がIssue・プルリクエスト・コントリビューションを作成することを明示的に禁止している 興味深いのは、あわせて**AI発のコントリビューションを識別するシグナル**（特定のマーカーを含むIssue/PRは優先処理される）も用意している点です。禁止するだけでなく、識別できるようにしています。 ### 出力への署名義務 別のプロジェクトでは、エージェントが作成したメッセージに**`Drafted-by: ` フッターを義務化**し、人間レビューの有無も明記させています。 ### 物理的にブロックする 最も強い対策です。フックで検証スキップのコマンドをシステムレベルでブロックし、**AIが「テストが通らないなら飛ばす」を物理的にできなくしています。** ### 要点 - **自律性境界は規約レベルだけでなく、フック・CI・ファイル分離など多層で実装されている** - **AI出力をリポジトリ上で識別可能にする**ことで、人間レビュアーが確認の濃度を変えられる - **技術仕様とガバナンスのファイル分離は、更新責任が異なることを反映した設計**——前者は開発者、後者はメンテナや法務 ## 分類E：コミュニケーション境界 見落とされやすい観点です。 OSSではIssue・PR・コミットメッセージが公開されます。**セキュリティ修正で攻撃ベクターを露出すると、修正前のバージョンを使っているユーザーが攻撃されます。** そのため、あるプロジェクトでは**ブランチ名・コミットメッセージ・テスト記述・コードコメントのすべてについて「攻撃ベクターを一切露出しない」ルール**を設けています。 | | 例 | | --- | --- | | **良い** | `fix/auth-edge-case` | | **避ける** | `fix/auth-bypass-via-jwt-replay` | テストコメントについても、**攻撃の再現方法を直接書かない**としています。 **AIは「分かりやすい名前を付ける」ことを良いことだと判断します。**セキュリティ修正の文脈では、それが逆効果になることを明示する必要があります。 ## 自社に適用するときの順序 5分類のうち、どこから手を付けるべきか整理すると次のようになります。 1. **入出力境界**——脆弱性に直結するため最優先。CIでの強制もセットで 2. **自律性境界**——AIの出力が人の確認なしに反映される経路を塞ぐ 3. **アーキテクチャ境界**——コードを読んでも分からない不変条件を明示 4. **エディション境界**——該当するビジネスモデルの場合 5. **コミュニケーション境界**——公開リポジトリの場合 ## よくある質問 ### なぜ境界を明示する必要があるのですか？ **AIは「動くコード」を作るために最短経路を取ろうとするためです。**特にアーキテクチャ上の不変条件は、コードを読むだけでは見えません。「あえて書かない」という設計判断には痕跡が残らないためです。 ### 効果的な書き方はありますか？ **「絶対に〜しない」という否定形が、肯定形よりも境界として機能します。** ### ドキュメントに書けば守られますか？ **不十分です。**特に入出力境界のような脆弱性に直結する領域は、LintルールやCIチェック、フックによる物理的なブロックまで併用するのが望ましい実装です。 ### 技術仕様とガバナンスは同じファイルでよいですか？ **分離する例が観測されています。**更新責任が異なる（技術仕様は開発者、ガバナンスはメンテナや法務）ことを反映した設計です。 ## まとめ - 境界の表現は**アーキテクチャ／エディション／入出力／自律性／コミュニケーション**の5分類に整理できる - **「絶対に〜しない」という否定形**が境界として機能する - **アーキテクチャ境界はコードを読んでも見えない。**だから明示する意義がある - **技術的に自由に行き来できるものほど、明示的な禁止が必要**（エディション境界） - **AIは標準APIを使いがち。**独自ラッパーの強制は書かないと守られない - 自律性境界は**規約・フック・CI・ファイル分離の多層**で実装される - **AI出力を識別可能にする**と、人間レビューの濃度を変えられる - セキュリティ修正では**「分かりやすい名前」が逆効果**になることを明示する AIに任せる範囲が広がるほど、任せてはいけない範囲の定義が重要になります。書いていない制約は、守られないものとして扱う必要があります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Cookieをポートしてもボット検出は突破できない｜Browser Use Desktop Appの守備範囲 - URL: https://ai-katsu.jp/articles/browser-use-desktop-app - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-04T00:00:00+00:00 - Models: Claude, OpenAI API - Tools: Browser Use - Tasks: リサーチ・データ収集, ツール検証 > 普段使いのChromeのCookieをエージェント側にポートするBrowser Use Desktop Appを調査しました。認証済みSaaSの横断操作には強い一方、Cookieポートは「ログイン状態の継承」であって「フィンガープリントの継承」ではないため、ボット検出下のスクレイピングには使えません。残る4つの壁とコンプライアンス上の懸念もまとめています。 ブラウザ操作を自動化するAIエージェントで、実務上いちばんの障壁は**ログイン**です。認証済みのSaaSを操作させたいのに、エージェント側は毎回ログインからやり直しになります。 Browser Use Desktop Appは、この問題に**普段使いのChromeのCookieをエージェント側にポートする**という方法で答えています。ただし**この方式で解決すること・しないことの区別が決定的に重要**でした。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年5月4日 | | 対象 | Browser Use Desktop App（v0系・2026年初頭リリース） | | 方法 | **ドキュメントベースのデスクリサーチ**＋過去のBrowser Use CLI検証経験との比較 | | やりたかったこと | Cookieポート方式が、CLI版で頻発していたボット判定によるNGを緩和するか確認する | | 結論 | **認証済みSaaS横断は◎、ボット検出下のスクレイピングは✗** | | 判定 | **条件付きで導入可**（★4.0/5） | > 本記事はデスクリサーチ段階の記録です。実バイナリでの動作確認は未実施のため、実測値は含みません。 ## 結論：Cookieポートは「ログイン状態の継承」であって「指紋の継承」ではない この検証で最も重要な発見です。 **Cookieポートはあくまで「ログイン状態の継承」までで、フィンガープリント（ブラウザ指紋）の継承ではありません。** この区別が、使える用途と使えない用途を分けます。 | 用途 | 評価 | 理由 | | --- | --- | --- | | **認証済みSaaS横断タスク** | **◎** | Cookieポートが効く定番ユースケース | | **ボット保護下のスクレイピング** | **✗** | Cookieをポートしても**フィンガープリント不一致で即無効化** | ボット検出は、Cookieだけを見ているわけではありません。**ブラウザの指紋が一致しなければ、認証済みのCookieを持っていても弾かれます。** **「Cookie認証が生きていれば任意のSaaSを自動化できる」という素朴な仮説には、4つの壁が残ります。** 1. **MFA / SSO の再認証**（銀行・管理者系・SAML SSO） 2. **フィンガープリント**（デバイス/IPバインドCookieの即時無効化） 3. **Shadow DOM**（多用するSaaSではDOM解釈精度が低下） 4. **ToS違反リスク**（自動化を禁止するサービスではアカウントBAN対象） ## Cookieポートという発想 とはいえ、適した用途では強力です。 **普段使いのChromeのCookieを、専用のクリーンなChromiumにポートし、ログイン済み状態でエージェントを起動する**——これがこのアプリの中核機能です。 ポイントは**「普段使いのChromeを汚さない」**点にもあります。別プロセスとして起動するため、自分の作業中のブラウザとエージェントが干渉しません。 ### 効くユースケース たとえば「議事録をNotionに起票して、Linearにチケットを切って、Slackに通知して」といったタスクです。**3つのSaaSすべてにログイン済みの状態で、Chromiumが順次操作します。** API連携を組めば同じことはできますが、**それぞれのAPIキーを発行し、認証を通し、実装する必要があります。**Cookieポート方式なら、その工程が不要になります。 ## WhatsApp経由のリモート発火 独自性が高い機能として評価しているのがこれです。 **自分のWhatsAppに `@BU ◯◯して` と送信すると、自宅PCのDesktop Appがエージェントセッションを起動します。** 外出先やモバイルから、手元にないPCの上でタスクを走らせられます。**デスクトップエージェントを「常駐型秘書」化する仕組み**という位置づけです。 あわせて**グローバルショートカット**にも対応しており、任意のアプリから即座にタスクを投入できます。起動の動線が「Raycast的」な軽快さで、**CLIを触らずに済むため非エンジニアへの配布障壁が低い**設計です。 ## Browser Useの3形態 提供側の戦略として整理できる点です。 | 項目 | Desktop App | CLI / SDK | MCP | | --- | --- | --- | --- | | 機能性 | GUI＋Cookieポート＋並列管理 | コードで何でも組める | LLMクライアント側のツール呼出 | | **使いやすさ** | **◎（非エンジニアOK）** | △（要コーディング） | ○（クライアント次第） | | 連携性 | ショートカット / WhatsApp | コード経由で何でも | MCPクライアントに依存 | | カスタマイズ性 | 中 | **高** | 中 | **CLI / SDK・MCP・Desktop Appという3形態に分化し、ユーザー層別の最適解を提示する戦略**と読めます。Desktop Appはその中でエンドユーザー常駐型に振った異色の存在です。 ## マルチエージェント並列実行 GUI上で複数タスクを並行管理できる点も差別化要素です。**CLI版を自前で並列化するより手軽**という評価になっています。 上限はマシンリソース依存です。 ## セキュリティ・コンプライアンス上の懸念 この構成には、無視できない論点があります。 **普段使いのChrome Cookieをプロセス間で移動させるため、社内コンプライアンス（特にSSOセッショントークンの取扱い）に抵触する恐れがあります。** | 評価項目 | 評価 | 詳細 | | --- | --- | --- | | 暗号化 | △ | ChromeのCookie復号 → 別Chromium移植の経路はリスク面 | | アクセス制御 | △ | **グローバルショートカットで誰でも発火可能**（PCに物理アクセスがあれば） | | **コンプライアンス** | **✗** | **社用PCのSSO Cookie移植は社内ポリシーと衝突する可能性** | **個人環境での試用が現実解**という結論です。社用PCでの利用は、事前確認なしに進めるべきではありません。 ## 技術的リスク - **MFA/SSO再認証で詰まる**（銀行・管理者系・SAML SSO） - **デバイス/IPバインドCookieの即時無効化** - **ChromeのCookie暗号化ストレージ仕様変更で破綻**（Keychain / DPAPI） - **JS重め・Shadow DOM多用SaaSではDOM解釈精度が低下** - **ToS違反リスク** — 自動化を禁止するサービスではアカウントBAN対象 3つ目が特に構造的な問題です。**Chrome側の仕様変更で動かなくなる可能性が常にあります。**公式にサポートされた連携方法ではないため、追従が必要になります。 ## 用途の見極めが最重要 この検証のTipsとしてまとめられている内容です。 - **適性領域を見極めて使う** — 認証済み社内SaaS横断は◎、ボット検出下のスクレイピングは✗ - **個人環境で試す** — 社用PCではSSO Cookie取扱いの観点でNGの可能性大 - **ステルス突破が必要なら専用ツールと併用** — Desktop Appは本来そういう用途のツールではない **ツールの守備範囲を誤ると、動かない理由を延々と探すことになります。**この検証の価値は、その境界を先に明確にした点にあります。 ## よくある質問 ### Cookieをポートすればボット検出を回避できますか？ **できません。**Cookieポートは「ログイン状態の継承」であって「フィンガープリントの継承」ではありません。指紋が一致しなければ、認証済みCookieを持っていても即座に無効化されます。 ### どんな用途に向いていますか？ **自分が普段ログイン済みのSaaSを横断操作する用途です。**Notion・Linear・Slack・社内管理画面などを続けて操作するタスクで効果が出ます。 ### 社用PCで使えますか？ **事前確認が必要です。**SSOセッショントークンをプロセス間で移動させるため、社内ポリシーと衝突する可能性があります。個人環境での試用が現実解です。 ### CLI版と比べてどうですか？ **使いやすさとCookieポートで優位、カスタマイズ性で劣ります。**プロンプト・ツール定義・モデル選択の柔軟性が必要ならCLI/SDK版の併用が現実的です。 ## まとめ - **Cookieポートは「ログイン状態の継承」であって「指紋の継承」ではない。**この区別が用途を決める - **認証済みSaaS横断は◎、ボット検出下のスクレイピングは✗** - 残る4つの壁は**MFA / フィンガープリント / Shadow DOM / ToS** - **WhatsApp経由のリモート発火とグローバルショートカット**で「常駐型秘書」的な使い方ができる - **社用PCのSSO Cookie移植は社内ポリシーと衝突する可能性。**個人環境での試用が現実解 - Chromeの暗号化ストレージ仕様変更で**破綻するリスクが構造的に残る** 自動化ツールを評価するときは、できることの一覧より「どこまでは無理か」を先に確認しておくと判断が早くなります。境界が分かれば、そこに合う使い道が見えてきます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## GAS×YouTube Data APIでリサーチ自動化｜非エンジニアに渡せる形まで作る - URL: https://ai-katsu.jp/articles/gas-youtube-data-api - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-03T00:00:00+00:00 - Models: Claude Code - Tools: Google Apps Script, YouTube Data API - Tasks: 業務自動化・ワークフロー, ツール検証 - Domain: マーケティング > ノーコードツールとAPI直叩きの中間として、GAS＋スプレッドシート＋図形ボタンでYouTubeのトレンド動画リサーチを自動化しました。初期設定約10分・費用0円で、1キーワードあたり30分の手作業が数秒に。APIキー管理が不要になる拡張サービス方式と、「人気順」と「トレンド」が別物である落とし穴もまとめています。 業務の自動化には、だいたい3つの選択肢があります。**ノーコードツール、API直叩き、そしてその中間。**この検証は「中間がちょうどいい場面がある」という仮説の確認です。 GAS（Google Apps Script）とスプレッドシートでYouTubeのトレンド動画リサーチを自動化し、**図形ボタンを押すだけで非エンジニアも実行できる形**まで持っていきました。**初期設定は約10分、費用は0円**です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月3日〜（検証中） | | 構成 | GAS拡張サービス経由の YouTube Data API v3 + スプレッドシート + 図形ボタン | | やりたかったこと | トレンドキーワードに対する人気動画リサーチの自動化／非エンジニアでも実行可能な配布形態にする | | 初期設定時間 | **約10分**（スプシ作成〜API有効化〜サンプル実行） | | 費用 | **0円**（GAS / YouTube Data API いずれも無料枠内） | | 効果 | 1キーワードあたりの手動リサーチ**30分 → 数秒** | | 判定 | **条件付きで導入可** | ## 結論：「画数がちょうどいい」ラインが存在する この検証の仮説は、次のものでした。 - YouTube Data APIを直接叩くのは非エンジニアには敷居が高い - ノーコードツール（Make / n8n等）で組むのも面倒で過剰 - **その中間として、GAS + スプレッドシート + 図形ボタンが適切なのではないか** 結果は**概ねYes**でした。 | 項目 | GAS × YouTube API | Make / n8n | API直接（Python等） | | --- | --- | --- | --- | | 機能性 | ◎（APIフル機能） | ○（コネクタ依存） | ◎ | | コスト | **無料** | 有料プラン必要なことが多い | 無料 | | 使いやすさ | ○ | ◎ | △（環境構築が必要） | | 連携性 | ◎（スプシ・Gmail等と直結） | ◎ | △ | | **配布のしやすさ** | **◎（スプシ共有＋ボタン）** | △（アカウント共有が面倒） | × | **差がつくのは「配布のしやすさ」です。**スプレッドシートを共有してボタンを押してもらうだけなら、相手側に何の準備も要りません。 ## APIキー管理が不要になる 技術的に効いたのがこれです。 **GASのエディタから「サービス」としてYouTube Data API v3を追加すると、`YouTube.Search.list()` などのメソッドがGASのネイティブ関数のように呼び出せます。** OAuthスコープは初回実行時に承認ダイアログが出るので、そこで許可するだけです。**APIキーの発行・保管・ローテーションといった作業が発生しません。** この方式は他のGoogle APIにも使えます。**Gmail API、Tag Manager API、YouTube Analytics APIも同様に有効化できます。** ## AIにコードを書かせる前提の作り方 この検証で実際に回したワークフローです。 1. Claude Codeに「再生数降順 / トップ50 / 公開日・URL含む / シートに書き出し」を**自然言語で依頼** 2. 生成コードをGASに貼り付け 3. 実行して結果を確認 **条件を箇条書きで投げるだけで、生成コードは一発で動きました。** 精度を上げるコツも記録されています。**参考サイトのURL（GAS YouTube Data APIのリファレンス等）も併せて渡すと精度が上がります。** さらに運用の形として、**既存のGASコードをAIに貼り付け → 自然言語でアップデート要件を伝える → 修正版コードをGASに戻す、というループが回ります。**コードを書けなくても、改修を続けられる状態になります。 ## 「人気順」と「トレンド」は別物 この検証で最も実用的な発見です。 `order=viewCount` で再生数降順は問題なく機能します。しかし**「全期間で人気順」と「直近のトレンド」は別物です。** 実際に「ポケモンカード」で実行したところ、**2024年公開・7200万再生の動画がトップに来ました。**トレンドを知りたい目的には合いません。 **対策は `publishedAfter` による期間フィルタの併用です。**これを設計に入れないと、古い超人気動画ばかりが上位を占めます。 この検証では、**「人気順」「直近3ヶ月」など条件別に関数を分け、シートも分ける構成**にしました。あとから条件を追加しやすくなります。 ## Quota（利用上限）に注意 YouTube Data APIには1日あたりのユニット消費上限があります（無料枠で1日10,000ユニット程度）。 **`search.list` は1リクエストあたり100ユニットを消費するため、ループで投げると上限に到達しやすくなります。** 実務的な制限として、**一度に投げるキーワードは5件程度**が現実的という結論です。 その他の制約も整理しておきます。 - 1回の `search.list` で取得できるのは**最大50件**。それ以上はページトークン連結が必要（200件程度まで） - **動画URLはAPIレスポンスに含まれない** → `https://www.youtube.com/watch?v=` + 動画IDで文字列結合して生成 - GASの実行時間制限（6分）があるため、大規模並列処理・長時間処理には向かない ## 非エンジニアに渡す形にする 配布形態の設計もこの検証の目的でした。 **スプレッドシートのA1以降にキーワードを並べ、図形ボタンに実行関数を割り当てる**——この構成で、非エンジニアがそのまま使える状態になります。 細かい配慮も記録されています。**完了通知の `Browser.msgBox()` は非エンジニアには却って分かりづらいため、コメントアウトするかそもそも実装しないほうがよい**という点です。 **作る側が「親切」と思う機能が、受け取る側には邪魔になることがあります。** ## つまずいた点 | 症状 | 原因 | 対処 | | --- | --- | --- | | `Error, please try again later.`（500系） | サーバー側の問題 | 少し待って再実行（リトライ実装で解消） | | 書き込み先シートでエラー | ヘッダー行が空 | 事前にヘッダー行をコピーしておく | | 一部キーワードの結果が取得できない | 要デバッグ | Quota上限を考えると一度に5件程度までが現実的 | | 「サービス追加」が見つからない | UI上わかりにくい | 薄い「+」ボタンを探す | ## よくある質問 ### なぜノーコードツールを使わないのですか？ **この用途では過剰であり、配布も面倒だからです。**スプレッドシート1枚で完結し、共有してボタンを押してもらうだけで使えるほうが展開しやすくなります。 ### APIキーの管理は必要ですか？ **不要です。**GASの拡張サービス方式ならOAuth承認だけで済み、APIキーの発行・保管が発生しません。 ### 「人気順」で取得すればトレンドが分かりますか？ **分かりません。**全期間の再生数降順では古い超人気動画が上位を占めます。トレンドを見るには `publishedAfter` による期間フィルタの併用が必須です。 ### 1日にどのくらい実行できますか？ **`search.list` は1リクエスト100ユニット消費し、無料枠は1日10,000ユニット程度です。**一度に投げるキーワードは5件程度が現実的です。 ## まとめ - ノーコードとAPI直叩きの**中間（GAS + スプレッドシート + 図形ボタン）がちょうどいい場面がある** - 差がつくのは**配布のしやすさ**。スプシを共有してボタンを押してもらうだけで済む - **GAS拡張サービス方式ならAPIキー管理が不要**（OAuth承認のみ）。Gmail・Tag Manager等も同方式 - **「全期間で人気順」と「直近のトレンド」は別物。**`publishedAfter` の併用が必須 - `search.list` は**1リクエスト100ユニット**消費。一度に5件程度が現実的 - **動画URLはAPIが返さない**ため、動画IDから組み立てる - 既存コードをAIに渡して自然言語で改修するループが回るため、**コードを書けなくても改修を続けられる** 自動化の手段は、機能の多さより「渡す相手が使えるか」で選ぶと外しません。実行のハードルが下がるほど、実際に使われる回数が増えます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## サーバー不要でLINE×AIチャットボットを作る｜Difyの4ノード構成と5秒ルール対策 - URL: https://ai-katsu.jp/articles/line-dify-chatbot - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-03T00:00:00+00:00 - Models: Claude - Tools: Dify, LINE - Tasks: ナレッジ活用・RAG, ツール検証 > Difyのワークフロー機能だけで、サーバーレスにLINE × LLMの双方向連携を実現しました。最重要はasync_mode: trueの設定で、これがないとLINEの5秒ルールに引っかかり再送が続きます。replyTokenの30秒制限、RAGへの拡張パス、本番運用に足りないセキュリティ要件までまとめています。 LINE上でAIチャットボットを動かすには、通常Node.jsやPythonのサーバーが必要です。PoC段階でそこまで用意するのは、コストに見合いません。 この検証では、Difyのワークフロー機能だけで**サーバーレスにLINE × AIの双方向連携**を実現しました。**構成は4ノード、初期設定は約30〜60分**です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年5月3日 | | 構成 | Dify 0.6.0（ワークフロー）× LINE Messaging API／LLM: claude-haiku-4-5-20251001 | | やりたかったこと | コード最小限でLINE ↔ LLMの双方向連携を実現し、最小構成での動作を確認する | | 結果 | **4ノード構成で完全動作。手動テスト10回中10回成功** | | 応答速度 | LINE送信〜返信受信まで**3〜6秒** | | 初期設定時間 | 約30〜60分 | | 判定 | **条件付きで導入可**（PoC・プロトタイプ用途） | ## 結論：`async_mode: true` が必須設定 この検証で最も重要な発見です。 **LINEやSlackなど「5秒ルール」を持つWebhook統合では、`async_mode: true` が必須設定です。これを外すとLINEが再送を繰り返します。** LINEのWebhookは、5秒以内にレスポンスを返さないと再送が発生します。しかしLLMの処理は数秒かかります。**デフォルト設定（`async_mode: false`）で試したところ、タイムアウトエラーが連続発生しました。** **「受け付けたことをすぐ返し、処理は後で行う」——非同期化がこの構成の前提条件になります。** ## アーキテクチャ：4ノードで完結する ``` LINE ユーザー ↓（テキストメッセージ送信） LINE サーバー ↓（Webhook POST: events[].message.text + replyToken） Dify: Webhook トリガーノード（async_mode: true） ↓ Dify: コード実行ノード（Python3 でペイロードを解析） ↓（text, replyToken, messageType を出力） Dify: LLM ノード（回答生成） ↓（回答テキスト） Dify: HTTP リクエストノード（LINE Reply API へ POST） ↓ LINE ユーザーへ返信 ``` **サーバーのホスティング・管理が一切不要**である点が最大のメリットです。 ## ペイロード解析のガード処理 コード実行ノードのPythonは短いものですが、1点だけ実務的な工夫があります。 ``` def main(arg1: dict) -> dict: body = arg1.get("body") or {} events = body.get("events") or [] event = events[0] if events else {} message = event.get("message") or {} message_type = message.get("type") or "" return { "text": message.get("text", "") if message_type == "text" else "", "replyToken": event.get("replyToken", ""), "messageType": message_type, } ``` **`events[0] if events else {}` というガード処理が効きました。**LINEの検証用Webhookは `events` 配列が空の状態で飛んでくるため、これがないとエラーになります。 あわせて、**テキスト以外（スタンプ・画像等）が来た場合のハンドリング**もコードノードに入れておくと安定します。 ## つまずいた点 | エラー・症状 | 原因 | 対処法 | | --- | --- | --- | | **LINEから返信が来ない（タイムアウト）** | `async_mode` が false | Webhookノードの `async_mode: true` を設定 | | replyTokenが空で返信失敗 | events配列が空、またはノードID間違い | ガード処理と変数参照のノードIDを確認 | | 401 Unauthorized | Authorizationヘッダーの書き方誤り | **`Bearer チャネルアクセストークン`（波括弧なし）**で記述 | | 変数が `undefined` になる | 変数参照構文のノードIDが間違い | YAMLの `id` フィールドを確認 | Difyの変数参照は `{{#ノードID.変数名#}}` 形式で、**ノードIDはYAML上の `id` フィールドの値**です。慣れるまでは分かりにくい部分です。 もう1点、地味に引っかかるのがAuthorizationヘッダーです。**YAMLのコメントにプレースホルダーとして波括弧が書かれていることがありますが、実際の記述に波括弧は不要です。** ## replyTokenの30秒制限 本番運用を考えるうえで押さえるべき制約です。 **LINEのreplyTokenは発行から30秒で失効します。**LLMの処理が長引く場合、返信できなくなります。 対策は**Push API（`/v2/bot/message/push`）への切り替え**です。事前にユーザーIDを取得・保存しておく必要がありますが、replyTokenの制限から解放されます。 **短い応答ならReply API、長文生成や重い処理を挟むならPush API**——という使い分けになります。 ## RAGへの拡張パスが明確 この構成の将来性として評価している点です。 ``` コード実行ノード ↓ 知識検索ブロック ← Dify ナレッジ（PDF・テキスト等を事前登録） ↓ LLM ノード（ナレッジを context として参照して回答） ↓ HTTP リクエストノード（LINE 返信） ``` **コード実行ノードとLLMノードの間に知識検索ブロックを1つ挟むだけで、FAQ Bot・社内規定参照Botに変わります。** 汎用的なQ&Aから、自社のドキュメントを参照するボットへ——**この移行コストが低いことが、PoCから先へ進める条件になります。** ## コスト | 項目 | 内容 | 金額 | | --- | --- | --- | | Dify Cloud | Freeプランで月200メッセージ | 0円（有料プラン $59/月〜） | | LINE Messaging API | 月200通まで無料 | 0円（超過分 ¥3/通〜） | | LLM（Haiku） | トークン従量課金 | 入力 $0.80 / 出力 $4.00 per MTok | **PoC段階なら実質0円で試せます。**本番運用ではDifyのプラン上限とLINEの通数課金が効いてきます。 ## セキュリティ上の課題 この構成のまま本番に出すべきではない点も記録しています。 - **チャネルアクセストークンをHTTPノードのヘッダーにベタ書きしている** → 環境変数化が必要 - **署名検証（`x-line-signature`）が未実装** → Webhook URLを知られると偽リクエストを受け付ける - Dify Cloudにメッセージが通過するため、**機密情報を送らせない設計が必要** - Dify Cloudのデータ保管地域を確認すること **PoCで動かすことと、本番で運用することの間には、この差があります。**署名検証は特に、外部から叩かれる前提のエンドポイントでは必須です。 ## 他の構成との比較 | 項目 | Dify + LINE | n8n + LINE | 自前Pythonサーバー | | --- | --- | --- | --- | | 構築コスト | **低（ノーコード）** | 低〜中 | 高 | | **ホスティング** | **不要** | 自前またはクラウド | 自前必須 | | LLM切り替え | 容易（ノード変更） | 容易 | コード変更必要 | | RAG拡張 | **簡単（ブロック追加）** | プラグイン依存 | 自前実装 | | カスタマイズ性 | 中 | 高 | 最高 | ## よくある質問 ### サーバーは必要ですか？ **不要です。**DifyのWebhookトリガーがエンドポイントになるため、ホスティングも管理も発生しません。 ### LINEからの返信が来ません **Webhookノードの `async_mode` が `true` になっているか確認してください。**デフォルトの `false` のままだと、LINEの5秒ルールに引っかかってタイムアウトが連続します。 ### 本番運用できますか？ **この構成のままでは推奨できません。**チャネルアクセストークンの環境変数化と、署名検証（`x-line-signature`）の実装が必要です。またDify Freeプランのメッセージ数上限にも注意が必要です。 ### 社内FAQ Botに拡張できますか？ **できます。**コード実行ノードとLLMノードの間に知識検索ブロックを1つ追加するだけです。ファイルをアップロードして登録すれば対応できます。 ## まとめ - **4ノード構成でLINE × AIチャットボットがサーバーレスに動作**（手動テスト10回中10回成功） - **`async_mode: true` が必須設定。**LINE / Slackの「5秒ルール」を持つ統合では外せない - ペイロード解析には**events配列が空の場合のガード処理**を入れる - **replyTokenは30秒で失効。**処理が長い場合はPush APIへ切り替える - **知識検索ブロックを1つ挟むだけでRAG対応**。PoCから先への移行コストが低い - 本番運用には**トークンの環境変数化と署名検証の実装**が必要 - PoC段階なら**実質0円**で試せる AIチャットボットは、動かすところまでは短時間で到達できます。差が出るのは、そこから本番運用の要件を満たすまでの部分です。何が足りないかを最初に把握しておくと、判断が早くなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAIチャットボット導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Supabaseで医療系SaaSを設計する｜3省2ガイドライン対応とAI連携の安全原則 - URL: https://ai-katsu.jp/articles/supabase-medical-system-qa - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-02T00:00:00+00:00 - Models: Claude Code - Tools: Supabase, MCP - Tasks: 開発・エンジニアリング, ツール検証 > 医療クリニック向けSaaSをSupabaseで構築する際の論点を整理しました。PITR要件がプラン選択を決める構造、clinic_id＋RLSによるマルチテナント設計、ゼロトラストが必須要件ではない理由、東京リージョンでも国内要件を満たさない点、そしてAIにDBを触らせる際の安全原則までをまとめています。 医療系システムをクラウドで構築するとき、技術選定より先に決まってしまうことがあります。**法令・ガイドラインの要件が、使えるプラン・構成を絞り込む**ためです。 この検証では、Supabaseで医療クリニック向けSaaS（電子カルテ・薬品在庫・予約管理等）を設計する際の論点を、**アーキテクチャからコンプライアンス、AI連携時の安全原則まで**整理しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 作成日 | 2026年5月2日 | | 対象 | 医療クリニック向けSaaS（電子カルテ・薬品在庫・予約管理等） | | 整理した範囲 | Supabaseのアーキテクチャ設計／3省2ガイドライン対応／監査ログ・バックアップ設計／Claude Code連携時の安全原則 | | 本番最小構成 | **約$140/月**（Pro $25 + Small compute $15 + PITR 7日 $100） | > 本記事は技術設計上の整理であり、法的助言ではありません。実際の導入判断にあたっては、必ず最新のガイドライン原文を確認し、必要に応じて専門家にご相談ください。情報は2026年5月時点のものです。 ## 結論：ガイドラインが構成を決める 医療系で特徴的なのは、**技術的な最適解と、法令要件を満たす構成が一致しない場面がある**ことです。 典型例がPITR（Point In Time Recovery）です。 **PITRの利用にはPro Plan以上に加えて、Small compute add-on以上が必要です（Microでは不可）。**つまり「バックアップ要件を満たす」という一点で、コンピュートのプランまで決まります。 結果として、日本案件で3省2ガイドラインに適合させる本番最小構成は次のようになります。 | 構成 | 月額目安 | 用途 | | --- | --- | --- | | Pro $25 + Small compute $15 + PITR 7日 $100 | **約$140/月** | 日本案件・本番最小構成 | | Team $599 + Small compute $15 + PITR $100 + HIPAA add-on | 約$1,000〜1,500/月 | HIPAA対応が必要な場合 | ## アーキテクチャ：1プロジェクト + clinic\_id + RLS マルチテナント設計の選択肢は3つありますが、推奨は明確です。 **推奨: 1 Supabase Project + 共通DB + `clinic_id` + RLS（Row Level Security）** | 方式 | 評価 | | --- | --- | | **shared schema + clinic\_id + RLS** | **推奨。**開発・運用・AI連携・管理画面がシンプル | | スキーマ分離 | クリニック増加時のマイグレーション・横断集計・保守が重い | | プロジェクト分離 | 分離度は最高だが、Auth/Storage/Functions/Secrets/費用管理が増える | プロジェクト分離への移行を検討すべきタイミングも整理しています。**完全分離・個別バックアップ・個別SLA・大規模施設のリソース分離が必要になったとき**です。 **最初から最も分離度の高い構成を選ぶと、運用対象が増えて管理が破綻します。**必要になったら移行する、という判断が現実的です。 ## トランザクション設計：アプリ側で複数クエリを投げない ここは業務システムで事故になりやすい箇所です。 | 処理の性質 | 実装方式 | | --- | --- | | 単純CRUD（一覧取得、基本情報更新） | Supabase Client + RLS | | **ACID必要な業務処理**（予約確定・処方確定・在庫減算） | **Postgres関数/RPC（1トランザクション）** | | 外部API連携・秘密鍵・複雑検証・通知 | Edge Functions → 単一RPC呼び出し | | **アプリ側で複数クエリを順番に投げる** | **原則禁止** | 禁止する理由は、**途中失敗・二重送信・ロールバック漏れのリスク**です。処方確定や在庫減算が中途半端な状態で止まると、データの整合性が崩れます。 見落としやすい点があります。**Edge Functionsで複数のSupabase APIを順番に呼ぶだけでは、1トランザクションになりません。**「サーバー側で処理しているから安全」という理解は誤りです。 ## e-文書法の三原則をどう満たすか 電子カルテ・診療録を電子保存する場合、3つの要件を満たす必要があります。 | 要件 | 内容 | 実装例 | | --- | --- | --- | | **真正性** | 入力者の識別と認証 | MFA必須、supa\_audit/pgauditで変更履歴記録 | | **見読性** | いつでも読める状態 | 可用性設計、RTO/RPO定義 | | **保存性** | 指定期間の保存 | PITR、**診療録は患者最終来院から5年保存**、Log Drains外部転送 | **「5年保存」という要件が、ログの外部転送を必要にします。**プラットフォームのログ保持期間はプラン依存であり、数年規模の保管には対応できません。 ## 監査ログ設計の限界も含めて整理する 提案時に重要な姿勢として、**「医療グレード」と断定せず、要件→実装策→ギャップの順で整理する**ことを挙げています。 | 種別 | 実装方法 | 制約 | | --- | --- | --- | | 変更履歴 | supa\_audit（トリガー方式） | 書込3k ops/sec超えるテーブルには不向き | | 閲覧ログ | pgaudit | **`pgaudit.log_parameter` はHosted版で変更不可**（SELECTバインド値の詳細ログに限界） | | 長期保管 | Log Drains → S3/BigQuery等 | Logs Explorerの保持はプラン依存 | | 重要業務 | RPC/Edge Functions内で明示的に監査ログを書き込む | — | **できないことを先に明示するほうが、後の信頼につながります。**特に監査ログは「取れているはず」と思われたまま進むと、監査時に問題になります。 ## ゼロトラストは「必須」ではない 誤解されやすい論点です。ガイドライン第6.0版の記述を正確に読むと、こうなっています。 > 「ゼロトラスト思考に基づく対策を**必須としているわけではなく**、リスク分析の結果や、費用対効果も考慮したうえで判断することが望ましい」 **「境界防御を捨ててゼロトラストへ」ではなく「境界防御をしっかり固めた上で、ゼロトラストを段階的に取り入れる」が正しい読み方**です。 小〜中規模クリニックで優先すべき実装（境界防御）は次のとおりです。 - Network Restrictions（IP allowlist） - SSL Enforcement - **管理ダッシュボードへの2FA必須化** - **service\_role key / secret keyのサーバー側限定** - Cloudflare等のWAF/CDN（フロント側） 端末認証・SIEM・SOC・常時セッション検証といったゼロトラスト要素は、中長期で段階導入する位置づけです。 **ガイドラインを「全部やらないといけないもの」と読むと、実現不能な要件になります。**原文の表現を確認することが重要です。 ## HIPAAは日本の医療機関には原則対象外 これも整理が必要な論点です。 **HIPAAは「患者の国籍」ではなく「米国のCovered Entity（医療機関・健康保険）かどうか」で適用されます。**日本国内のクリニックは、患者が日本人・在日外国人であっても直接の適用対象外です。 したがって「慣習的にHIPAAを使う前提」も日本市場では成立しません。**日本で参照すべきは3省2ガイドラインです。** なお、SupabaseでHIPAA BAAを締結する場合は**Team Plan以上 + HIPAA add-onの申請が必要（Pro Planでは不可）**です。 ## 日本国内リージョンでも「国内サーバー要件」を満たすとは限らない 見落とされやすい論点です。 - Supabaseの契約主体はシンガポール法人 - **Tokyoリージョン（ap-northeast-1）を選択するだけで「日本国内サーバー」要件を満たすわけではない** - 個情法28条「外国にある第三者への提供」または法23条「外的環境の把握」のいずれかに該当しうる - **契約主体・サブプロセッサー（AWS等）・サポート対応国の整理が必要** **データの物理的な保管場所と、法的な取り扱いは別の問題です。**リージョン設定だけで安心してはいけません。 ## バックアップ：RPO/RTOを先に決める - **PITR利用要件**: Pro Plan以上 + **Small compute add-on以上（Microでは不可）** - PITR有効時は日次バックアップが置き換わる - 日次バックアップ保持期間: Pro 7日 / Team 14日 / Enterprise 最大30日 - **医療系推奨ライン: RPO=数分単位、RTO=数時間レベル** - **本番投入前にステージングで復元手順をリハーサルする** 最後の項目が実務的に重要です。**バックアップは取っているかではなく、戻せるかで評価すべきものです。**手順を試していなければ、あるだけの状態になります。 あわせて、可用性の考え方も整理されています。**医療系では「SaaS障害ゼロ」を前提にしない。**当日患者リストの定期エクスポート・キャッシュを検討し、RTO/RPO・障害時連絡先・復旧判断者を事前に決めておきます。 ## AIにDBを触らせるときの安全原則 この設計で特に重要な部分です。開発効率のためにAIを使う場合でも、越えてはいけない線があります。 ### 環境を2つに分ける | 環境 | 用途 | AI操作 | | --- | --- | --- | | ステージングProject | 開発用（**架空・匿名化データのみ**） | 読み書き・破壊的操作・ALTER TABLE直生成OK | | 本番Project | 実運用（実患者データ） | **AIツールを直接接続しない** | ### AIに渡してよいもの・渡してはいけないもの | 渡してよい | 渡してはいけない | | --- | --- | | スキーマ（テーブル定義、型情報） | **行データ（要配慮個人情報）** | | 架空・匿名化データのステージングDB | service\_role key | スキーマについても注意点があります。**テーブル名にクリニック固有情報が含まれる場合は配慮が必要です。** ### 安全原則 1. 接続先はステージングProjectのみ。**本番には直接つながない** 2. **破壊系コマンド（DROP TABLE / TRUNCATE / db reset 等）は人間が確認してから実行** 3. **service\_role keyをAI実行環境に置かない**（個人OAuth/PATで認証） 4. **AI生成SQLは必ずmigrationファイル化 + PRレビューを通す** 5. アクセストークンは環境変数（`.env` gitignore済み）で管理 **AIの生成物をそのまま本番に適用しない、という一点が守られていれば、多くの事故は防げます。**レビュー可能な形（migrationファイル）を経由させることが仕組み上の担保になります。 ## CLIとMCP、どちらでAIをつなぐか **推奨: CLI（Git Bash経由）を基本、MCPは補助** | 観点 | CLI | MCP | | --- | --- | --- | | **コンテキスト消費** | **ほぼゼロ** | 10〜15k tokens / メッセージ（200kウィンドウの5〜10%） | | 操作範囲 | CLI全機能（db pull/push/diff/dump/migration/gen types等） | MCP公開ツールに限定 | | UNIXツール連携 | grep/sed/awk/jqとシームレスに連携 | 別途bash必要 | **MCPは1メッセージあたり10〜15kトークンを消費します。**常時つないでおくと、会話の余裕が削られます。探索的な操作や他ツールとの横断ワークフローに限定し、使う場合は最小スコープ（`read_only=true` 等）にするのが現実的です。 ## 本番反映の4ステップ 1. ステージングで試作（AI経由でフリーに変更） 2. 確定したスキーマを `supabase db pull --linked` 等でmigrationファイル化、**PRレビュー** 3. リセット済みステージングに `db push` でリハーサル。アプリの主要動線確認 4. 本番に `db push`（リード担当 or CI経由）+ **切り戻し手順を事前に用意** 切り戻し手順の最低ラインは次の3点です。 - PRにこのmigrationが何を変えたか明記 - **ロールバック用の逆SQLを用意** - **本番適用前にPITRの復元ポイントを確認** ## RLS未設定というリスク マルチテナント構成で最も重大な事故は、テナント間のデータ漏えいです。 - **全テーブルでRLS有効化を原則にする** - 患者/予約/処方/会計などのデータは `clinic_id` 条件を必須化 - **テストユーザーA/Bで「別テナントのデータが読めない・書けない」自動テストを作る** - **Security Advisor警告ゼロを本番リリース条件にする** **RLSは「設定した」ではなく「破れないことをテストで確認した」状態にして初めて意味を持ちます。** APIキーの扱いも同様です。**anon keyの安全性はRLS設計に完全に依存します。**service\_role keyはサーバー側限定で、フロント・Git・AIへのプロンプトに出してはいけません。 ## 2027年度以降の義務要件 今後を見据えた要件も記録しておきます。 **新規導入または更新する医療情報システムには、二要素認証の採用が義務化されます（2027年度以降）。** いま設計するシステムは、この時期に更新対象となる可能性があります。**後から足すより、最初から組み込んでおくほうが安く済みます。** ## よくある質問 ### マルチテナントはどう設計すべきですか？ **1プロジェクト + 共通DB + `clinic_id` + RLSが推奨です。**スキーマ分離はマイグレーションと横断集計が重くなり、プロジェクト分離は管理対象が増えます。完全分離や個別SLAが必要になった段階で移行を検討します。 ### 日本の医療機関でもHIPAA対応は必要ですか？ **原則不要です。**HIPAAは米国のCovered Entityに適用されるもので、日本国内のクリニックは直接の対象外です。参照すべきは3省2ガイドラインです。 ### 東京リージョンを選べば国内要件を満たせますか？ **満たすとは限りません。**契約主体が海外法人である場合、個情法28条または法23条の論点が生じます。契約主体・サブプロセッサー・サポート対応国の整理が必要です。 ### AIにデータベースを触らせても大丈夫ですか？ **ステージング環境（架空・匿名化データのみ）に限定すれば可能です。**本番には直接接続せず、生成されたSQLは必ずmigrationファイル化してPRレビューを通します。行データは絶対に渡しません。 ## まとめ - 医療系では**ガイドライン要件が構成を決める。**PITR要件だけでコンピュートのプランまで確定する - マルチテナントは**1プロジェクト + `clinic_id` + RLS**が基本。分離は必要になってから - **Edge Functionsで複数APIを順に呼んでも1トランザクションにはならない。**ACIDが必要な処理はRPCで - **ゼロトラストは必須要件ではない。**境界防御を固めたうえで段階導入が正しい読み方 - **HIPAAは日本の医療機関には原則対象外。**参照すべきは3省2ガイドライン - **東京リージョンを選ぶだけでは国内要件を満たさない。**契約主体とサブプロセッサーの整理が必要 - AI連携は**ステージング限定・行データを渡さない・migrationファイル経由でPRレビュー**が原則 - **2027年度以降、二要素認証が義務要件**になる 規制のある領域では、技術選定の自由度は思ったより低くなります。要件を先に洗い出しておくと、実装に入ってからの手戻りを避けられます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のシステム設計とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AI開発の見積もりはどう作るか｜コーディング時間を計上しない3原則 - URL: https://ai-katsu.jp/articles/ai-dev-estimation-guide - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-05-02T00:00:00+00:00 - Tools: Supabase, Vercel - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: 営業 > AIがコードを書く時代の見積もりの考え方を、実案件から整理しました。工数の中身はコーディング中心から検証中心へ入れ替わります。人間が担う設定・確認・判断の3作業、4フェーズ分割による根拠づくり、バッファ率を言語化する方法までまとめています。 従来の開発見積もりは、**「コードを書く時間」が大部分を占めていました。**しかしAIがコードを書くようになると、その前提が崩れます。 この記事では、実際の移植案件での見積もり実務から整理した**AI活用開発の見積もりの考え方**をまとめます。 ## この記事の概要 | 項目 | 内容 | | --- | --- | | 作成日 | 2026年5月2日 | | 背景 | Next.js + Supabase構成のアプリ移植案件での見積もり実務 | | 主題 | **コーディング時間を計上しない**見積もりの組み立て方 | > 本記事に登場する金額は、単価を仮定した計算例です。当社の料金体系を示すものではありません。 ## 結論：工数の中身が入れ替わる | 作業 | 従来の工数 | AI活用後 | | --- | --- | --- | | **コーディング** | 60〜70% | **ほぼゼロ（AIが担当）** | | 設計・方針決定 | 10〜15% | 変わらず必要 | | **レビュー・テスト** | 15〜20% | **中心的な作業になる** | | **環境構築・設定** | 5〜10% | **割合として増える** | **エンジニアの価値は実装量ではなく、判断・検証・設計の質に移行しています。** ここを理解しないまま従来の見積もり方法を使うと、「AIを使うなら安くなるはずだ」という話と噛み合わなくなります。 ## 人間が担う3種類の作業 ### 1\. 設定作業（Configuration） 外部サービスの管理画面操作、環境変数の取得・設定、デプロイ設定など。 **AIは代替できません。**地味ですが、確実に時間がかかります。 - データベースのプロジェクト作成、認証設定、アクセス制御ポリシーの入力 - ホスティング環境の環境変数登録、ドメイン設定 - 外部APIのキー取得・制限設定 **ブラウザで管理画面を操作する作業は、コード生成の外側にあります。** ### 2\. 確認作業（Verification） AIが実装したコードを、実際にブラウザや管理画面で動かして正しいか確認する作業です。 **品質を担保する最後の砦であり、特に認証・権限まわりは念入りな確認が必要です。** 認証の確認パターンは、最低でも3つ必要になります。 - **管理者でログイン** → 管理画面が見える - **一般ユーザーでログイン** → 自分に紐づくデータのみ見える - **未認証** → 公開ページのみアクセス可 ### 3\. 判断作業（Decision） 設計の選択、仕様のトレードオフ、AIへの指示内容の決定。 **これが最も専門性が高く、単価に見合う部分です。** - アクセス制御の設計方針（テーブル単位か行単位か） - AI生成機能をAPIルートに分離するか、サーバーアクションにするかの判断 - 実行時間制限への対応方針（上位プランに上げるか、ストリーミングで回避するか） ## フェーズ分割で根拠を作る AI開発案件は、4フェーズに分けると工数の根拠を説明しやすくなります。 | フェーズ | 内容 | 工数の目安 | | --- | --- | --- | | **1\. 基盤構築・疎通確認** | 認証・DBの基本接続を動かす | 3〜4h | | **2\. DB構築・アクセス制御** | テーブル作成・ポリシー設定・型生成 | 3〜5h | | **3\. 機能動作確認** | 各機能をブラウザで操作して確認 | **機能数 × 0.5〜1.5h** | | **4\. デプロイ・最終確認** | 本番環境でのE2E確認 | 3〜4h | フェーズ3の粒度感が実務的です。 - **単純なCRUD確認**：0.5h - **外部連携（AI生成・ファイルアップロード）**：1〜1.5h - **認証・権限が絡む確認**：1〜2h **同じ「1機能」でも、認証が絡むかどうかで確認工数が3倍変わります。** ## バッファの根拠を言語化する | 案件の性質 | バッファ率 | 理由 | | --- | --- | --- | | PoC・初回導入 | **20%** | 想定外の設定ミス・サービス仕様変更が起きやすい | | 既存パターンの横展開 | **10%** | ハマりポイントが事前に予測しやすい | | 社内ツール・リスク低め | **0〜5%** | 想定外が少なく、追加請求しやすい関係性 | この案件（データベース初導入・アクセス制御設定あり）は**10%**が妥当な落とし所でした。 ## 詰まりやすいポイントをリスク費用の根拠にする 見積もり時にリスクを明示しておくと、追加費用が発生した場合の説明がしやすくなります。 | ポイント | 影響 | 対策 | | --- | --- | --- | | **アクセス制御の設定ミス** | 他ユーザーのデータが見える・見えないバグ | **3パターン（管理者/一般/未認証）で必ず確認** | | **関数の実行時間上限** | AI生成が60秒で切れる（無料プラン） | **早期に実測。**超える場合は上位プラン（約3,000円/月）を提案 | | 本番とローカルの環境差異 | OAuthリダイレクト失敗など | デプロイ直後にリダイレクトURLを追加する手順を事前に把握 | | 外部APIの認証設定 | CORS・ドメイン制限で動かない | **本番デプロイ後に確認する工数を見積もりに含める** | **「なんとなく20%」ではなく「この2点が不確定要素なので10%」と言える状態にしておく**ことが、バッファの説明力を決めます。 ## クライアントへの提示方法 ### 「正しく動かす費用」として説明する **「コードを書く費用」ではなく「正しく動かす費用」として説明します。** AIが書いたコードを正しく設定・検証・判断する専門性への対価、という位置づけです。 ### インフラ費用は開発費と分けて明記する **月額コストが後から発覚するとトラブルになりやすいためです。** あわせて**初期は無料プランで始められること**も伝えると、印象が変わります。 ### 工数の根拠を分解して見せる フェーズ×作業項目で分解すると、納得感が高くなります。 ## 金額感の参考（単価を仮定した計算例） 単価5,000円/hと仮定した場合の概算です。 | 案件規模 | 人間工数 | バッファ | 税込概算 | | --- | --- | --- | --- | | 小規模（PoC・3機能以下） | 8〜12h | 10% | 約5〜7万円 | | 中規模（多機能アプリ） | 15〜20h | 10% | 約9〜12万円 | | 大規模（複数ロール・外部連携多数） | 25〜35h | 20% | 約17〜23万円 | 見積もりの構成は次の順で組み立てます。 ``` 工数（h） × 単価 = 開発費小計 ↓ ＋ バッファ ↓ 税抜合計 ↓ ＋ 消費税 10% ↓ 税込合計 ``` ## よくある質問 ### AIを使うと見積もりは安くなりますか？ **コーディング工数は減りますが、設定・確認・判断の工数は残ります。**むしろ環境構築・設定は割合として増え、レビュー・テストが中心的な作業になります。 ### 何に対して費用をもらうのですか？ **「正しく動かす費用」です。**設定作業（AIが代替できない管理画面操作）、確認作業（品質担保の最後の砦）、判断作業（設計の選択）の3種類が人間の担当範囲になります。 ### バッファは何%が妥当ですか？ **案件の性質によります。**PoC・初回導入なら20%、既存パターンの横展開なら10%、リスクの低い社内ツールなら0〜5%が目安です。重要なのは率より、その根拠を言語化しておくことです。 ### 工数見積もりの粒度は？ **4フェーズに分割し、機能確認は機能数×0.5〜1.5hで積みます。**単純なCRUDは0.5h、認証・権限が絡むと1〜2hと、3倍程度の幅があります。 ## まとめ：3つの原則 - **コーディング時間は計上しない。**AIが書く。人間の時間は設定・確認・判断に集中させる - **詰まりやすいポイントを事前にリスト化してバッファの根拠にする。**「なんとなく20%」ではなく理由を言える状態にする - **インフラ費用は開発費と分けて明示する。**月額費用を事前に伝えないと信頼を損なう 加えて押さえておきたい点です。 - 工数の中身は**コーディング中心から検証中心へ入れ替わる** - **認証が絡む確認は工数が3倍**になりうる - 提示は**「コードを書く費用」ではなく「正しく動かす費用」**として AIが実装を担うようになっても、見積もりが不要になるわけではありません。何に時間がかかるかが変わっただけで、その内訳を説明できるかが信頼を左右します。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発内製化とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## LINEマーケティングをOSSでセルフホストする｜5,000人まで無料の構成と選定基準 - URL: https://ai-katsu.jp/articles/line-harness-oss - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-28T00:00:00+00:00 - Tools: LINE, Cloudflare, MCP - Tasks: 開発・エンジニアリング, ツール検証 > ステップ配信・セグメント配信・リッチメニューをCloudflare上にセルフホストするOSSを調査しました。友だち5,000人まで完全無料という構成ですが、判断軸はコストではなくデータ所有とAPI公開・MCP対応によるAI連携です。セットアップで詰まりやすい認証情報とLINE側の応答設定もまとめています。 LINEマーケティングツールは月額数千円〜数万円が相場です。ステップ配信・セグメント配信・リッチメニューといった機能を使うには、それだけのコストがかかります。 この調査では、**同等の機能をOSSでセルフホストする選択肢**を整理しました。**友だち5,000人までなら完全無料**という構成です。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査日 | 2026年4月28日 | | 対象 | LINE Harness OSS v0.4.0（MCP対応）／ライセンス: MIT（商用利用可） | | やりたかったこと | 既存の有償LINEマーケティングツールと同等の機能をOSSで実現できるか確認する／AIから自然言語でLINE運用を完結させる可能性を探る | | 構成 | **完全セルフホスティング型**（自分のCloudflareアカウントにデプロイ） | | 状況 | **未検証（調査・セットアップ設計まで）** | > 本記事は調査段階の記録です。実際のセットアップ・動作検証は未実施のため、動作結果や所要時間の実測値は含みません。 ## 結論：コストではなく「データをどこに置くか」で選ぶ 費用差だけを見ると、OSSが圧倒的に有利に見えます。しかし判断軸はそこではありません。 | 観点 | OSS（セルフホスト） | SaaS型ツール | | --- | --- | --- | | 月額 | **0円**（Cloudflare費のみ） | 数千円〜数万円 | | **データ所有** | **自分のCloudflare** | SaaS側 | | **API公開** | **全機能公開** | 非公開が多い | | AI連携 | **MCP対応** | 難 | | 権限管理・サポート | 自前 | 整備されている | 使い分けの基準を整理するとこうなります。 - **まず0円で仕組みを体感したい** → セルフホスト型OSS - **企業チームで本格運用したい**（権限管理・ノウハウ蓄積） → 既存の有償ツール - **LINE + LP + 決済 + 会員サイトを一体で運用したい** → その機能を持つ統合型SaaS **OSSの価値は無料であることより、APIが全機能公開されていてAIから操作できる点にあります。**管理画面を開かずに運用を完結させたい場合、この差は大きくなります。 ## 技術構成 | レイヤー | 技術 | | --- | --- | | API / Webhook | Cloudflare Workers + Hono | | DB | Cloudflare D1（SQLite、**42テーブル**） | | 管理画面 | Next.js 15 + Tailwind CSS | | LIFF | Vite + TypeScript | | 定期実行 | Workers Cron Triggers（5分ごと） | | CI/CD | GitHub Actions | すべてCloudflare上で完結する構成です。**DBが42テーブルという規模は、単純な配信ツールではないことを示しています。** ## コスト構造 | 友だち数 | コスト | | --- | --- | | **0〜5,000人** | **完全無料**（Cloudflare無料枠内） | | 5,000〜10,000人 | 約 $10/月（Cloudflareのみ） | | 50,000人以上 | 約 $25/月 | **ソフトウェア本体は永久に0円で、かかるのはインフラ費のみ**という構造です。友だち数が増えても、SaaSの従量課金と比べると増え方が緩やかになります。 ## 機能比較 基本的な配信機能は一通り揃っています。 - ステップ配信 - セグメント配信 - リッチメニュー - LIFFフォーム - Stripe決済統合 - **IF-THEN自動化（7×6完全対応）** 一方で**LP機能は持っていません。**LINE配信とLPを一体で管理したい場合は、統合型のSaaSのほうが適しています。 ### 独自機能：BAN検知・自動移行 他ツールにない差別化要素として挙げられているのがこれです。 **検知・ステルスモード・バックアップアカウント自動移行の3層構成**になっています。 LINE公式アカウントの運用では、アカウント停止は事業継続に直結するリスクです。**停止を検知して別アカウントへ移行する仕組みを持つかどうかは、リスク設計の話になります。** ## AIから操作する：MCP対応 v0.4.0でMCPに対応しています。**MCPの16ツールを通じて、AIから自然言語でLINE運用を操作できる**設計です。 「友だち数を教えて」「特定セグメントに配信して」といった指示が想定されています。 **管理画面のUIを覚える必要がなくなる**点が本質的な変化です。操作方法ではなく、やりたいことを伝えれば済みます。 ## セットアップで押さえるべき点 実施は未着手ですが、手順の整理から分かる注意点があります。 ### 取得が必要な認証情報は5つ 1. Messaging API Channel ID 2. Messaging API Channel secret 3. チャネルアクセストークン（長期） 4. **LINEログイン チャネルID** 5. **LINEログイン チャネルシークレット** **④⑤のLINEログイン系を忘れやすい点が要注意です。**UUID取得・BAN移行・流入経路追跡がこれに依存します。Messaging APIの分だけ用意しても機能が揃いません。 ### LINE側の応答設定 Webhook URL登録後、次の設定が必要です。 - あいさつメッセージ → **オフ** - Webhook → **オン** - 応答メッセージ → **オフ** **応答メッセージをオフにしないと、LINE側とツール側で二重応答になります。**「メッセージが2回届く」という症状の原因はほぼこれです。 ## 想定されるトラブルと対処 | 症状 | 原因 | 対処 | | --- | --- | --- | | Webhook Verify 失敗 | URLが違う・Workers未デプロイ | URL末尾に `/webhook` が付いているか確認し、再デプロイ | | 401 Unauthorized | APIキー不一致 | 管理画面側の環境変数とWorkers側のシークレットが同じ値か確認 | | 友だち追加しても管理画面に表示されない | Webhookが無効 | LINE Official Account Managerで応答設定 → Webhookをオンに | | **挨拶メッセージが二重に届く** | LINE側の自動応答がオン | **応答メッセージ・あいさつメッセージを両方オフに** | | Cloudflare APIトークンエラー | トークン期限切れ・権限不足 | ダッシュボードでトークンを確認・再発行して再設定 | ## 導入前に確認すべきこと OSSのセルフホストを選ぶ場合、コスト以外の負担も見積もる必要があります。 - **アップデートの追従は自分で行う**（SaaSのように自動では上がらない） - **障害時の切り分けも自分で行う**（サポート窓口がない） - **認証情報の管理責任が自分側にある** - 権限管理やチーム運用の仕組みは自前で用意する必要がある **「無料」はソフトウェアのライセンス費用の話であり、運用コストがゼロになるわけではありません。**小規模で試す、あるいは技術リソースがある前提なら有力な選択肢になります。 ## よくある質問 ### 本当に無料で運用できますか？ **友だち5,000人まではCloudflareの無料枠内で完全無料です。**10,000人規模で約$10/月、50,000人以上で約$25/月。ソフトウェア本体は永久に0円です。ただし運用・保守の手間は自分側で負担します。 ### 有償ツールとの一番の違いは？ **データを自分のCloudflareに置ける点と、APIが全機能公開されている点です。**逆にLP機能は持たず、権限管理やサポートは自前になります。 ### AIから操作できますか？ **v0.4.0でMCPに対応しており、16ツールを通じて自然言語で操作できる設計です。**管理画面を開かずに運用を完結させることが想定されています。 ### セットアップで詰まりやすい点は？ **LINEログイン系のチャネルID・シークレットの取得漏れと、LINE側の応答設定です。**応答メッセージをオフにしないと二重応答になります。 ## まとめ - LINEマーケティング機能を**Cloudflare上にセルフホストするOSS**という選択肢がある（MITライセンス・商用利用可） - **友だち5,000人まで完全無料**。ソフトウェア本体は永久0円で、かかるのはインフラ費のみ - OSSの本質的な価値は無料であることより**データ所有・API全機能公開・MCP対応によるAI連携** - **LP機能は持たない。**一体運用したい場合は統合型SaaSのほうが適する - 独自機能として**BAN検知・ステルスモード・バックアップアカウント自動移行の3層構成** - セットアップでは**LINEログイン系の認証情報**と**応答メッセージのオフ設定**が要注意 - **「無料」はライセンス費の話。**アップデート追従・障害対応・認証情報管理は自分側の負担になる ツール選定では、月額費用の比較だけで決めると運用負担を見落とします。データをどこに置くか、AIから操作したいか——この2つを基準にすると判断しやすくなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Remotionで口パク動画を作る｜立ち絵1枚から自動生成する全工程 - URL: https://ai-katsu.jp/articles/remotion-lipsync-howto - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-28T00:00:00+00:00 - Models: Imagen - Tools: Remotion - Tasks: 資料作成・デザイン, ツール検証 > キャラクターの口パク動画を、立ち絵1枚から作る手順をまとめました。核心は音声解析でフレームごとの開閉を0/1配列に還元すること。あとはフレーム番号で引いて画像を差し替えるだけになります。表情差分4枚の作り方と、品質を左右する要素も解説します。 キャラクターが喋る動画を作るとき、口の動きを手作業で合わせるのは現実的ではありません。**音声から自動で口パクを生成できれば、ナレーション動画を量産できます。** この記事では、**立ち絵1枚から口パク動画を作るまでの全工程**を、素材準備と実装の2フェーズに分けて整理します。 ## この記事の概要 | 項目 | 内容 | | --- | --- | | 作成日 | 2026年4月28日 | | やること | 立ち絵1枚 → 表情差分4枚 → 音声解析 → 口パク動画 | | 使用ツール | Remotion / FFmpeg / 表情差分生成ツール / 画像生成AI | | 所要目安 | 表情差分の生成は**慣れると約3〜5分** | ## 全体フロー ``` [立ち絵1枚] ↓ 表情差分生成ツール [表情差分4枚（2×2グリッド）] ↓ [Remotionプロジェクト]＋[音声ファイル]＋[FFmpeg] ↓ 口パク解析スクリプト [mouth-cues.json] ↓ Composition.tsx [口パク動画] ``` ## 結論：口パクは「フレームごとの0/1」に還元できる この手法の核心はここです。 **音声を解析して、フレームごとに口が開いているか閉じているかを 0/1 の配列にします。** ``` { "fps": 30, "mouthByFrame": [0, 1, 1, 0, 1, 0, ...] } ``` あとは**フレーム番号でこの配列を引き、対応する画像に差し替えるだけ**です。 ``` import { useCurrentFrame } from 'remotion'; import mouthCues from './lipsync/mouth-cues.json'; // フレームに対応する口の状態を取得 const frame = useCurrentFrame(); const isMouthOpen = mouthCues.mouthByFrame[frame] === 1; // 状態に応じて画像を切り替える const mouthImage = isMouthOpen ? 'eye-open_mouth-open.png' : 'eye-open_mouth-close.png'; ``` **複雑に見える口パクが、中間表現をJSONに落とすことで単純な画像切り替えになります。** ## PHASE 1：表情差分を4枚用意する ### ステップ1：立ち絵をグリッド化 キャラクター画像を**2×2グリッド形式**に変換して保存します。 ### ステップ2：画像生成AIで表情差分を作る グリッド画像を参考画像として添付し、**4パターンを1枚の2×2画像として生成**するよう指示します。 | 位置 | 内容 | | --- | --- | | 左上 | 未使用（元画像のまま） | | 右上 | 目開き | | 左下 | 目閉じ・口閉じ | | 右下 | 目閉じ・口開き | **品質を安定させるコツ**があります。 - **差分の品質が微妙な場合は新規チャットで再生成する** - **ベース画像は「目と口が同じ状態」のものが推奨** - 慣れると**約3〜5分で完成** ### ステップ3：パーツ抽出して4パターンを保存 生成画像を分割・位置合わせし、**ブラシで目と口の領域をマスク**して4パターンを一括保存します。 | ファイル | 表情 | | --- | --- | | `eye-open_mouth-close.png` | 目開・口閉 | | `eye-open_mouth-open.png` | 目開・口開 | | `eye-close_mouth-open.png` | 目閉・口開 | | `eye-close_mouth-close.png` | 目閉・口閉 | **目と口を独立して組み合わせるため、4枚で足ります。**瞬きと口パクを別々に制御できます。 ## PHASE 2：Remotionで実装する ### プロジェクト構成 ``` project/ ├── public/ │ └── audio/ │ └── narration.wav ← 音声ファイルをここに配置 ├── scripts/ │ └── generate-lipsync.mjs ← 音声解析スクリプト └── src/ ├── lipsync/ │ └── mouth-cues.json ← 生成されるJSONデータ └── Composition.tsx ← メインのコンポーネント ``` ### 音声解析スクリプトの仕様 | パラメータ | 値 | | --- | --- | | FPS | **30** | | サンプルレート | **16000** | | 出力先 | `src/lipsync/mouth-cues.json` | **FFmpegで音声を解析し、フレームごとの口開閉データをJSONで出力します。** 実行はコマンド1つです。 ``` node scripts/generate-lipsync.mjs ``` ### 動作確認 開発サーバーを起動してブラウザでプレビューを確認します。解像度の調整が必要な場合はComposition設定で変更します。 ## AIにコードを書かせる場合の分け方 参考にした記事では、**3パターンのプロンプト**を用意する方法が推奨されています。 | パターン | 用途 | | --- | --- | | **統合版** | スクリプト（.mjs）＋TSXを一括生成 | | スクリプト単独版 | 音声解析スクリプトのみ生成 | | TSX単独版 | コンポーネントのみ生成 | 重要なのは渡し方です。**各プロンプトにファイルパス・fps・サンプルレート・出力形式を明記して渡します。** **数値と出力先を先に固定しておくと、生成物同士が噛み合います。**片方だけ生成し直しても整合が取れます。 ## つまずきポイント - **FFmpegは必須。**PATH設定が通っていないと解析スクリプトが動かない - **表情差分はベース画像の「目と口の状態」を統一しておくと差分品質が安定する** - 解像度調整はAIへの追加指示で対応可能 - **口パクの精度はFFmpegの音声解析精度に依存するため、クリアな音声ファイルを用意する** 最後の項目が品質を左右します。**ノイズの多い音声では、口の開閉判定が乱れます。**素材の段階で決まる部分です。 ## よくある質問 ### 表情差分は何枚必要ですか？ **4枚です。**目の開閉と口の開閉を独立して組み合わせるため、2×2の4パターンで足ります。 ### 口パクはどう実現していますか？ **音声を解析して、フレームごとに口が開いているかを0/1の配列にします。**あとはフレーム番号で配列を引き、対応する画像に差し替えるだけです。 ### 精度を上げるには？ **クリアな音声ファイルを用意することです。**口パクの精度は音声解析の精度に依存するため、素材の段階で品質が決まります。 ### AIにコードを書かせられますか？ **できます。**ただしファイルパス・fps・サンプルレート・出力形式を明記して渡してください。数値と出力先を固定しておくと、スクリプトとコンポーネントの整合が取れます。 ## まとめ - 口パクは**「フレームごとの0/1配列」に還元できる**。中間表現をJSONに落とすのが要点 - 表情差分は**目×口の2×2で4枚**あれば足りる - 差分生成は**ベース画像の目と口の状態を統一**すると品質が安定する（慣れると3〜5分） - **FFmpegは必須。**PATHが通っていないと解析が動かない - AIにコードを書かせるなら**パス・fps・サンプルレート・出力形式を明記**する - **最終的な品質は音声素材のクリアさで決まる** 複雑に見える処理も、中間表現を挟むと単純な処理の組み合わせになります。どこで形式を固定するかが、実装のしやすさを決めます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のコンテンツ制作へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 音声認識APIの選び方2026｜日本語精度・コスト・個人情報対応で比較する - URL: https://ai-katsu.jp/articles/stt-api-comparison - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-28T00:00:00+00:00 - Models: OpenAI API - Tools: ElevenLabs, Google Cloud - Tasks: 音声・翻訳・文字起こし, ツール検証 > 主要なSTT API 13サービスを日本語WER・コスト・レイテンシで横断比較し、用途別の推薦をまとめました。選定はまず「個人情報を含むか」で分岐します。医療データをクラウドで扱う3条件、GPUなしでも実用になるローカル運用、OpenAI互換サーバーによる移行コストの下げ方まで解説しています。 音声認識APIの選定は、精度・コスト・レイテンシの3軸で語られがちです。しかし**扱う音声に個人情報が含まれるかどうかで、選択肢そのものが変わります。** この調査では、主要なSTT（Speech-to-Text）APIを横断比較し、**用途別の推薦とローカル運用への切り替え基準**まで整理しました。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 最終更新 | 2026年5月1日 | | 対象 | 主要クラウドSTT API 13サービス／ローカルデプロイ可能なOSSモデル | | 比較軸 | コスト（1分あたり）／レイテンシ／日本語精度（WER）／データプライバシー | | 結論 | **新規・日本語精度重視ならElevenLabs Scribe v2／OpenAI互換のまま安くするならGroq Whisper v3 Turbo／個人情報・カルテを含むならローカルOSSまたは国産オンプレ** | > 本記事の料金・仕様・法令情報は2026年5月時点のものです。導入時は必ず最新の公式情報をご確認ください。法的判断が必要な場合は専門家にご相談ください。 ## 結論：まず「個人情報を含むか」で分岐する ``` 音声データに個人情報・カルテ情報が含まれる？ │ ├── YES │ ├── クラウドAPIで対応したい │ │ ├── ZDR + BAA 取得可能 → Azure Speech (Japan East) が最も整備済み │ │ └── 取得困難 or リスク回避 → ローカル or 国産オンプレへ │ ├── 自社サーバーあり（オンプレ） │ │ → Speaches + faster-whisper をDockerデプロイ │ └── 国産サポート・SLAが必要 │ → 国産の医療特化サービス │ └── NO（個人情報なし・一般用途） ├── 新規・日本語精度重視 → ElevenLabs Scribe v2 ← 大抵これでOK ├── OpenAI互換コード流用 → Groq Whisper v3 Turbo ├── バッチ最安値 → fal.ai Wizper ├── リアルタイム会話 → ElevenLabs Scribe v2 Realtime └── ミーティング文字起こし → Gladia Solaria-1 ``` **個人情報を扱わないなら、比較は素直に精度とコストで決まります。**扱うなら、まず法的要件を満たせる選択肢に絞ってから性能を見る、という順番になります。 ## 日本語精度（WER：低いほど高精度） | サービス | 日本語WER | | --- | --- | | **ElevenLabs Scribe v2** | **2.2%** | | Soniox | 8.7% | | Groq / fal.ai Wizper | 約5〜8%（Whisper large-v3相当） | | Deepgram Nova-3 | 11.7% | | OpenAI gpt-4o-transcribe | 13.8% | | Azure Speech | 14.0% | | Google STT | 14.2% | | AssemblyAI | 14.8% | | Amazon Transcribe | 16.2% | **差が大きすぎるため、精度が最優先なら選択肢は絞られます。**WER 2.2%と13.8%では、後工程の修正量がまったく変わります。 なお出典には注意が必要です。**Sonioxの数値は自社主催ベンチマークによるものでバイアスの可能性があります。**ベンチマークは誰が測ったかを確認する必要があります。 ## コスト（1分あたり） | サービス | バッチ | ストリーミング | 備考 | | --- | --- | --- | --- | | **ElevenLabs Scribe v2** | **$0.0037** | — | バッチ専用。精度業界最高 | | ElevenLabs Scribe v2 Realtime | — | $0.0065 | リアルタイム専用。150ms | | **Groq Whisper v3 Turbo** | **$0.00067** | — | **OpenAI完全互換**。最安バッチクラス | | **fal.ai Wizper** | **$0.0005** | — | 最安値。バッチ特化 | | Deepgram Nova-3 | $0.0043 | $0.0077 | 低レイテンシ・日英混在対応 | | Gladia Solaria-1 | $0.0041〜 | $0.0042〜 | ミーティング文字起こし特化 | | OpenAI gpt-4o-transcribe | $0.006 | $0.006 | 両対応 | | Google STT v2（Dynamic Batch） | $0.003 | $0.016 | 大量バッチに有利 | | Azure Speech | $0.006 | $0.0167 | **5時間/月無料枠。日本リージョンあり** | | Amazon Transcribe | $0.024 | $0.024 | 割高・15秒最低課金 | **精度最高のElevenLabsが最安クラスではないものの、$0.0037/分は十分に安価です。**OpenAI比で約40%安、Amazon比で約85%安になります。 ## レイテンシ（ストリーミング） | サービス | レイテンシ | | --- | --- | | **Gladia Solaria-1** | **103ms**（partials） | | **ElevenLabs Scribe v2 Realtime** | **150ms** | | OpenAI Realtime API | 約232ms（不安定報告あり） | | Deepgram Nova-3 | <300ms | | AssemblyAI | 約300ms | | Google STT v2 | 約350ms | | Azure Speech | 約450ms | | Amazon Transcribe | 600〜800ms | リアルタイム会話やコールセンター用途では、この差が体感に直結します。 ## 用途別の推薦 | ユースケース | 推薦 | 理由 | | --- | --- | --- | | 新規・日本語精度重視（個人情報なし） | **ElevenLabs Scribe v2** | WER 2.2%・コスト・リアルタイム全方位最良 | | OpenAI互換のまま移行したい | **Groq Whisper v3 Turbo** | $0.00067/分・**エンドポイントURLを変えるだけ** | | バッチ処理・コスト最安 | fal.ai Wizper | $0.0005/分・250x realtime速度 | | リアルタイム会話・コールセンター | ElevenLabs Scribe v2 Realtime | 150ms・話者分離32名 | | ミーティング・会議文字起こし | Gladia Solaria-1 | partials 103ms・話者分離込み | | 日本国内データ処理必須 | **Azure Speech（Japan East）** | APPI対応・国内処理が最も明確 | ## ElevenLabs Scribe v2 のトレードオフ 精度で選ぶ場合でも、割り切る点があります。 | 観点 | 評価 | | --- | --- | | 日本語精度 | ◎ WER 2.2%。「Excellent（WER≤5%）」を公式保証 | | 話者分離 | ◎ 最大32名まで対応。追加料金なし | | 多言語 | ◎ 99言語対応 | | **OpenAI互換** | **✕ 独自APIスキーマ。既存コードは移行作業が必要** | | **データ処理地** | **✕ 日本リージョンなし。音声データは米国処理** | | 個人情報・医療データ | ✕ 通常プランはNG | **既存コードがOpenAI SDK前提なら、Groq Whisperへの移行が現実的です。**エンドポイントURLの変更だけで済み、コストは$0.00067/分になります。 ## ローカルモデルが必要になる3つのケース ``` 1. 音声データに個人情報・要配慮個人情報が含まれる （医療カルテ、金融相談、弁護士相談 など） 2. 法的にデータを国外に出せない （厚労省ガイドライン第6.0版・APPI対応が必要） 3. 月100時間以上の大量処理でTCO最小化したい （月100時間超でローカルGPUがクラウドAPIより安くなる） ``` 法的根拠として、**厚生労働省「医療情報システムの安全管理ガイドライン第6.0版」（2023年5月）**では音声データが要配慮個人情報に該当し、クラウド利用時は「データ処理場所の明示」と「責任分界の書面化」が必須とされています。 また**APPI改正（2027年施行見込み）では、音声データが「生体データ」として特別カテゴリに分類される可能性**があります。これは特定のサービスの問題ではなく、**米国クラウドAPI全般に同様に適用されます。** ## 「API経由なら学習に使われない」は半分正しい | 観点 | 実態 | | --- | --- | | 学習への利用 | ✅ API経由はデフォルトで学習に使われない（主要サービス共通） | | **ログの保持** | **⚠️ OpenAIはデフォルト最大30日間保持される** | | ゼロ保持（ZDR） | Enterprise/Businessプランで申請可 | **学習利用の有無とログ保持は別の話です。**「学習に使われないから安全」という理解では不十分で、保持期間の確認が必要になります。 サービス別のポリシーには差があります。 | サービス | デフォルト学習利用 | 医療データ対応 | | --- | --- | --- | | OpenAI API | なし | 条件付き可（ZDRで保持0日） | | ElevenLabs | なし | BAA要問い合わせ | | **Azure Speech** | なし | **◎ Japan East + BAA整備済み** | | Google Cloud STT | なし | △ 要個別確認 | | **AWS Transcribe** | **あり（要オプトアウト）** | △ 日本語医療は限定的 | **AWSのみ「デフォルトで学習に使われる」設定です。**オプトアウトはAWS Organizationsポリシーで可能ですが、設定しないままだと意図しない利用になります。 ## 個人情報の扱いの判断基準 | ケース | 判断 | | --- | --- | | 個人情報なし（講義録音・会議メモ等） | ✅ 通常のAPI利用でOK | | 氏名・連絡先程度が含まれる | ⚠️ APPI越境移転同意の確認が必要 | | 医療カルテ・診察音声 | ❌ 通常プランはNG。**ZDR + BAA + APPI対応が必要** | 医療データをクラウドAPIで扱う場合の3条件は次のとおりです。 1. **ZDR（ゼロデータリテンション）を有効化** — Enterprise/Businessプランで個別申請 2. **BAA（Business Associate Agreement）を締結** 3. **日本APPIの越境移転要件を満たす** — 本人同意の取得、または十分な安全管理措置の整備 ## ローカルで動かす：GPUなしでも実用になる 「ローカル＝高性能GPUが必要」と思われがちですが、環境によって選択肢があります。 ### GPU環境 | モデル | 日本語精度(CER) | 速度 | 最小GPU | | --- | --- | --- | --- | | Whisper large-v3 | 8.5% | 標準 | RTX 3060(12GB) | | Whisper large-v3-Turbo | 8.8% | 5.4倍速 | RTX 3060(6GB) | | **faster-whisper（INT8量子化）** | 同等 | 4倍速 | RTX 3060 | | kotoba-whisper v2.2 | 9.2% | 6.3倍速 | RTX 3060(8GB) | **実運用の推奨は `faster-whisper large-v3 INT8`** です。VRAMを削減しつつ速度が出ます。 ### Apple Silicon（GPUなし） | チップ | 10分音声の処理時間 | RTF | | --- | --- | --- | | M1（MacBook Air） | 約3分 | 0.30x | | M2（MacBook Air） | 約2.5分 | 0.25x | | M3 Pro | 約1.5分 | 0.15x | | M4 Pro | 約50秒 | 0.08x | RTF < 1.0はリアルタイムより速いことを意味します。**M1でも十分実用的です。**推奨ツールは `mlx-whisper`（faster-whisperはNVIDIA GPU前提のためApple Siliconでは非効率）。 ### x86 CPU **`small` がCPU専用の実用ライン**（RTF 約0.1〜0.2）です。`large-v3`（量子化なし）はRTF 2.5以上でCPU単独では非現実的。ツールは `whisper.cpp` が適します。 ## ローカル運用のコスト分岐点 | 選択肢（月500時間処理） | 月額 | 初期費用 | | --- | --- | --- | | ElevenLabs Scribe v2 | 約$1,110/月 | なし | | OpenAI gpt-4o-transcribe | 約$1,800/月 | なし | | ローカル（GPU購入） | 電気代+保守のみ | 約$2,000 | | **GPUクラウドインスタンス借用** | **約$200〜250/月** | なし | **月500時間規模では、GPUクラウドの借用がコスト面で最も有利になります。**ただしデータは外部に出るため、個人情報を扱う場合は選択肢になりません。 ## ローカルモデルをAPIとして公開する 既存コードを活かす方法があります。**OpenAI互換APIを提供するOSSサーバー**を使う構成です。 ``` from openai import OpenAI client = OpenAI(api_key="dummy", base_url="http://localhost:8000") with open("audio.mp3", "rb") as f: result = client.audio.transcriptions.create( model="Systran/faster-whisper-large-v3", file=f ) print(result.text) ``` **`docker-compose up` 1コマンドで起動し、OpenAIの `/v1/audio/transcriptions` と完全互換**のため、既存のOpenAI SDKコードをエンドポイントURLの変更だけで流用できます。 **「クラウドAPIからローカルへの移行」が、コードの書き換えなしで済むかどうかは移行コストを大きく左右します。** ## よくある質問 ### 日本語で一番精度が高いのはどれですか？ **ElevenLabs Scribe v2（WER 2.2%）です。**「Excellent（WER≤5%）」を公式に保証しており、次点との差も大きくなっています。 ### 既存のOpenAI SDKコードを活かしたい場合は？ **Groq Whisper v3 Turbo（$0.00067/分）が現実的です。**OpenAI完全互換のため、エンドポイントURLを変えるだけで移行できます。 ### 医療データや個人情報を含む音声は？ **通常のクラウドAPIプランでは扱えません。**クラウドで対応するならZDR + BAA + APPI越境移転要件の3条件が必要で、Azure Speech（Japan East）が最も整備されています。リスク回避ならローカルOSSまたは国産オンプレです。 ### GPUがなくてもローカルで動きますか？ **動きます。**Apple SiliconならM1でもRTF 0.30x（10分音声を約3分）で実用的です。x86 CPUでは `small` モデルが実用ラインになります。 ## まとめ - 選定はまず**「個人情報を含むか」で分岐**する。含むなら法的要件を満たす選択肢に絞ってから性能を見る - 日本語精度は**ElevenLabs Scribe v2（WER 2.2%）が突出**。次点とは大きな差がある - 既存のOpenAI SDKコードを活かすなら**Groq Whisper v3 Turbo（$0.00067/分・完全互換）** - **「学習に使われない」とログ保持は別の話。**OpenAIはデフォルト30日保持、AWSはデフォルトで学習利用 - 医療データをクラウドで扱うには**ZDR + BAA + APPI越境移転要件**の3条件 - **GPUがなくてもローカルは実用的。**Apple SiliconならM1でRTF 0.30x - OpenAI互換のOSSサーバーを使えば、**ローカルへの移行がエンドポイント変更だけで済む** APIの選定は、性能表を見比べるだけでは決まりません。扱うデータの性質を先に確認しておくと、そもそも比較すべき対象が変わります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の音声AI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## GCP組織ポリシーを開けっぱなしにしない｜タグ方式で最小権限を保つ認証設計 - URL: https://ai-katsu.jp/articles/gcp-auth-security - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-28T00:00:00+00:00 - Tools: Google Cloud, GitHub, Cloudflare - Tasks: 開発・エンジニアリング, ツール検証 > Google Drive APIを使う自動化で認証が通らず、組織ポリシーをOFFにして全プロジェクトが解放される——という状態から、Google公式推奨のタグ方式へ移行する設計を整理しました。作業順序を間違えると既存キーが無効化される点、WIF（キーレス認証）が使える環境と使えない環境の切り分けもまとめています。 Google Drive APIを使う自動化を作ろうとすると、必ず認証で止まります。そして**「動かないから組織ポリシーをOFFにする」**という対処をしてしまうと、組織全体が開けっぱなしになります。 この検証では、その状態から**最小権限を実現するタグ方式**への移行方針を整理しました。あわせて**WIF（キーレス認証）が使えるプラットフォームと使えないプラットフォーム**も切り分けています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月28日〜（検証中） | | 上位の目的 | ニュースサイトを自動クローリングし、記事タイトル・本文・URLをGoogle Drive / Docsに自動格納するシステムを構築する | | この検証の焦点 | APIキー直書き運用を脱し、セキュアな認証方式へ移行する／GCP組織ポリシーの正しい運用方法を理解する | | 技術要素 | GitHub Actions / Render / Google Drive API v3 / GCP IAM / Workload Identity Federation | | ランニングコスト見込み | **ほぼ$0**（各サービスの無料枠内） | | 状況 | 設計整理完了・実作業は未実施 | ## 結論：組織ONのまま、タグで個別に除外する GCP組織ポリシーの階層と上書きルールを整理すると、こうなります。 ``` 組織レベルで Enforce=ON → プロジェクト単位での上書きは不可能 組織レベルで Enforce=OFF → 全プロジェクトが解放される（開けっぱなし） 正解: 組織ON + タグ方式で特定SAのみ除外 ``` **「プロジェクト単位で解除すればいい」という発想は通りません。**組織レベルで強制されている場合、プロジェクトからの上書きはできない仕様です。 結果として、動かすには組織レベルをOFFにするしかなく——**そうすると全プロジェクトが解放されます。**これが多くの人が陥る状態です。 正解は**Googleが公式に推奨するタグ方式**です。組織全体はONに戻したうえで、必要なサービスアカウントだけをタグで個別に除外します。 ## なぜこの問題が起きるのか 背景には仕様変更があります。 ``` 2024/05/03: 新規作成組織で disableServiceAccountKeyCreation がデフォルトON（強制）に変更 2024/06/16: 漏洩キーの自動無効化もデフォルト化 → この日以降に作ったGCP組織では初期状態でキー作成不可 ``` **この日以降に作られた組織では、サービスアカウントキーが最初から作れません。**以前の手順書どおりに進めても止まります。 もうひとつ注意点があります。**Double-lock**です。 ``` iam.disableServiceAccountKeyCreation（新） iam.disableServiceAccountKeyCreation（legacy） の2つが存在しており、両方解除しないと動かない場合がある ``` ## タグ方式の移行手順 前提として、組織レベルで次のロール付与が必要です（**プロジェクトレベルでは付与不可**）。 ``` roles/orgpolicy.policyAdmin （組織ポリシー管理者） roles/resourcemanager.tagAdmin （タグ管理者） ``` 1. **タグキーとタグ値を作成** — キー: `disableServiceAccountKeyCreation`／値: `enforced`（禁止）と `not_enforced`（許可） 2. **組織にデフォルトタグ（`enforced`）を付与** 3. **対象サービスアカウントに除外タグ（`not_enforced`）を付与** 4. **組織ポリシーを条件付きルールに更新** — 条件付きルールで `resource.matchTag(...)` が `not_enforced` のとき「強制しない」、デフォルトルールで「強制する」 5. **組織レベルのポリシーをONに戻す** ここで最も重要なのが**作業順序**です。 ``` ❌ NG: 組織ON → タグ設定（この間に既存キーが無効化される） ✅ OK: タグ作成 → SAにタグ付与 → 条件ポリシー設定 → 組織ON ``` **順序を間違えると、既存のキーが無効化されて動いていたものが止まります。**セキュリティ設定の変更では、締める前に例外を通しておく順番が必要です。 ## WIFが使える環境・使えない環境 実行環境の選定に直結する切り分けです。 ``` ✅ 使える: GitHub Actions, GitLab CI/CD, AWS EC2, Azure VM ❌ 使えない: Render, Fly.io, Railway, Cloudflare Workers, その他一般PaaS ``` **WIF（Workload Identity Federation）はOIDCトークンの発行が前提です。**一般的なPaaSはOIDCトークンを発行しないため、使えません。 この事実が、実行環境の選定を左右します。 | 実行環境 | 認証方式 | セキュリティ | | --- | --- | --- | | **GitHub Actions** | **WIF（キーレス）** | **JSONキー不要で最もセキュア** | | Render | サービスアカウントJSON | キーの管理・ローテーションが必要 | **キーが存在しなければ、漏洩のしようがありません。**WIFが使えるならそちらを選ぶのが基本です。 GitHub Actionsで使う場合、ワークフローに `id-token: write` の権限指定が必須になります。 ``` permissions: contents: read id-token: write # OIDCトークン発行に必須 ``` ## サービスアカウントキーを使う場合の運用ルール WIFが使えない環境では、キー方式になります。その場合に守るルールを整理しました。 1. **1 SA = 1キーのみ**（複数キーを持たない） 2. **スコープは `drive.file` のみ**（`drive` 全体は付与しない） 3. JSONキーはコードに直書きしない（環境変数で管理） 4. `.gitignore` に `*.json` を追加してコミット防止 5. **キーは90日でローテーション**（GCPコンソールで有効期限設定） 6. 不要になったキーはすぐ削除 7. **漏洩検知の自動無効化設定（`iam.serviceAccountKeyExposureResponse`）を有効に保つ** スコープについて補足があります。**`drive.file` スコープはアプリが作成したファイルのみアクセス可能**です。既存のDriveファイルへの読み書きには `drive` または `drive.readonly` が必要になる場合があります。 ## クローリング側で分かったこと 認証以外の検証結果も記録しておきます。 - **対象サイトのHTML直接fetchが可能**であることを実証（公式RSSがなくても対応可能） - 一覧ページから記事URLを抽出し、個別記事本文を取得する**二段構えfetch**のロジックを設計 - **非公式RSSは実用不可** — 2025年11月以降更新停止、または403でアクセス不可 - Claudeのコンテナからの直接fetchは「Host not in allowlist」でブロックされる（実行環境の制約） **非公式RSSに依存する構成は壊れます。**提供が止まっても誰も知らせてくれません。直接fetchのほうが、結果的に安定します。 ## Cloudflare Workersの無料枠を温存する コスト設計の工夫も記録されています。 ``` node-cronは使えない（常駐プロセスが存在しないため） 外部Cron（cron-job.org / GitHub Actions）が Worker の URL を HTTP GET で叩く → CronTrigger消費ゼロで同等の定期実行が実現できる ``` Cloudflare Workersの無料枠ではCron Triggerが5個/アカウントに制限されています。**外部Cronから叩く形にすれば、この枠を消費せずに定期実行できます。** ## よくある質問 ### プロジェクト単位で組織ポリシーを解除できませんか？ **できません。**組織レベルで強制されている場合、プロジェクト単位での上書きは仕様上不可能です。組織をONにしたままタグ方式で個別に除外するのが正しい方法です。 ### サービスアカウントキーが作れません **2024年5月3日以降に作られたGCP組織では、キー作成がデフォルトで禁止されています。**タグ方式で必要なサービスアカウントのみ除外してください。なお `disableServiceAccountKeyCreation` には新旧2つのポリシーが存在する場合があり、両方の対応が必要になることがあります。 ### WIFはどの環境で使えますか？ **GitHub Actions、GitLab CI/CD、AWS EC2、Azure VMなどOIDCトークンを発行する環境です。**Render、Fly.io、Railway、Cloudflare Workersなど一般的なPaaSでは使えません（2026年4月時点）。 ### タグ方式に移行する際の注意点は？ **作業順序です。**先に組織をONに戻すと、その時点で既存キーが無効化されます。タグ作成 → SAへのタグ付与 → 条件ポリシー設定 → 組織ON、の順で進めてください。 ## まとめ - GCP組織ポリシーは**組織レベルON時にプロジェクト単位での上書きが不可能**。OFFにすると全プロジェクトが解放される - 正解は**組織ON + タグ方式で特定サービスアカウントのみ除外**（Google公式推奨） - **作業順序が重要。**タグ作成 → SAにタグ付与 → 条件ポリシー設定 → 組織ON の順を守る - **WIF（キーレス認証）はOIDCトークン発行が前提。**一般PaaSでは使えない - キー方式なら**1SA=1キー・`drive.file` スコープ限定・90日ローテーション**を運用ルールにする - **非公式RSSは壊れる。**直接fetchのほうが結果的に安定する 自動化を作るとき、認証設定は「動けばいい」で済ませたくなる部分です。しかしそこで開けた穴は、全体に効いてきます。最小権限を保ったまま通す方法を先に確認しておくと、後から締め直す作業が不要になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化とセキュアな基盤づくりを支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Codexは速くて安い、ただし品質評価では負ける｜公開数値で見る2026年4月時点の比較 - URL: https://ai-katsu.jp/articles/openai-codex-2026 - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-28T00:00:00+00:00 - Models: OpenAI Codex, OpenAI API, Claude Code - Tasks: 開発・エンジニアリング, ツール検証 > 2026年3〜4月アップデート後のOpenAI Codexについて、公開されている数値を突き合わせて整理しました。処理速度240+トークン/秒、同タスクのコストは約1/10。一方でコード品質の盲目評価は25%対67%で逆転します。ベンチマークの比較可能性と料金体系の変更点もまとめています。 AIコーディングエージェントの比較記事は多くありますが、**速度・コスト・品質のどれを取るかで結論が変わります。**そして3つを同時に満たすツールは、現時点では存在しません。 この調査では、2026年3〜4月のアップデート後のOpenAI Codexについて、公開されている数値を突き合わせて整理しました。**速度はClaude Codeの約2.5倍、同タスクのコストは約1/10。ただし品質の盲目評価では逆転します。** ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査日 | 2026年4月28日 | | 対象 | OpenAI Codex（ChatGPT組み込み + Codex CLI）／「Codex for (almost) everything」2026年4月16日 | | 方法 | **WebSearchによる情報収集（実機検証なし）** | | やりたかったこと | Codexの現在の機能・価格・競合比較を一元的に把握し、AIコーディングエージェント選定の判断材料にする | | 判定 | **条件付きで導入可**（速度・コスト重視の用途に） | > 本記事は公開情報の調査記録です。実機検証は未実施のため、品質・体験の主観評価は含みません。 ## 結論：速度とコストは圧倒的、品質評価では劣る 数値を並べると、トレードオフが明確に見えます。 | 項目 | OpenAI Codex | Claude Code | | --- | --- | --- | | **処理速度** | **240+トークン/秒** | 相対的に低速 | | **コスト例**（Express.jsリファクタ） | **約$15** | 約$155 | | **コード品質（盲目評価）** | 優秀 25% | **優秀 67%** | | ベンチマーク | Terminal-Bench 2.0: **77.3%** | SWE-bench Pro: 64.3% | | Computer Use | **✅** | ❌ | | アーキテクチャ | クラウドネイティブ・非同期 | ターミナルファースト・インタラクティブ | **同じタスクでコストが約1/10になる一方、コード品質の盲目評価では優秀率が25%対67%と大きく開きます。** ここから導かれる使い分けは明快です。 - **速度・コスト重視の繰り返しタスク**（定型的なリファクタ等） → Codex - **品質重視のアーキテクチャ作業**（複雑なコードベース・設計判断） → Claude Code **コストが1/10なら、多少の手直しを前提にしても割に合う場面があります。**逆に、修正コストが高い設計作業では初回品質のほうが効きます。 ## ベンチマークの読み方に注意 比較表の数値には注意点があります。**Terminal-Bench 2.0とSWE-bench Proは別のベンチマークです。**77.3%と64.3%を直接比べることはできません。 それぞれ測っている対象が違います。**ベンチマークのスコアだけで優劣を判断すると誤ります。**同じ指標で比較されているか確認する必要があります。 この点、**盲目評価（どちらの出力か分からない状態での評価）の25%対67%のほうが、比較としては直接的です。** ## 2026年4月の主要機能 | 機能 | 内容 | | --- | --- | | **Computer Use** | Mac/WindowsアプリをCodex自身が直接操作（Figma・Xcode・Slack・ブラウザ等） | | **アプリ内ブラウザ** | Codexアプリ内でWebページをレンダリングし、直接コメントで指示 | | プラグイン（90以上） | CircleCI / GitLab Issues / Atlassian Rovo / Render / Microsoft Suite / CodeRabbit / Remotion 等 | | MCP | サードパーティツールとの連携 | | サブエージェント並列処理 | 複雑タスクを複数エージェントで分散処理 | **Computer Useが他社との大きな差別化要素**です。「見ながら操作できる」ことで、Figmaのデザインを渡してコードを生成するといった使い方ができます。 ただし**誤操作リスクがあるため、本番環境での利用は慎重に判断する必要があります。**画面を操作する以上、想定外の動作が実際の影響を持ちます。 また、**2026年3月にWindowsにも対応し、プラットフォーム制約が解消**されています。 ## 料金体系 | 項目 | 金額 | | --- | --- | | ChatGPT Plus | $20/月 | | ChatGPT Pro | $100〜$200/月 | | `codex-mini-latest` API | 入力 $1.50 / 出力 $6.00 per 1Mトークン | | **プロンプトキャッシュ** | **75%割引** | 重要な変更があります。**2026年4月2日に課金モデルがメッセージ単位からAPIトークン単位に変更されました。** この変更により、**キャッシュ活用（75%割引）の重要性が上がっています。**同じコンテキストを繰り返し送る使い方をしている場合、キャッシュが効くかどうかでコストが大きく変わります。 あわせて**GPT-5.5搭載により、同タスクをより少ないトークンで完了できる**とされています。単価だけでなく消費量も変数になります。 ## アーキテクチャの違いが使い方を決める 両者の設計思想は明確に異なります。 - **Codex** — クラウドネイティブ・非同期タスク処理。並列処理と長時間タスクに適した設計 - **Claude Code** — ターミナルファースト・インタラクティブ **非同期・並列タスク管理UIは、長時間タスクを複数走らせる使い方に向いています。**逆に、対話しながら詰めていく作業ではターミナルベースのほうが自然です。 なお、Codex CLIはRust実装のオープンソースで、デフォルトモデルは `codex-mini-latest` です。 ## 懸念点 - **コード品質の盲目評価でClaude Codeに大きく劣る**（25% vs 67%） - **複雑なコードベース・アーキテクチャ設計タスクは不向き** - クラウド実行のため**コードがOpenAIサーバーを経由する** - **Computer Useは誤操作リスクがある**（本番環境での利用は慎重に） - ChatGPTプラットフォーム依存（CLIはOSSだがモデルはOpenAI依存） ## よくある質問 ### CodexとClaude Code、どちらが優れていますか？ **用途によります。**速度は約2.5倍、同タスクのコストは約1/10でCodexが優位ですが、コード品質の盲目評価では優秀率25%対67%でClaude Codeが優位です。繰り返しタスクはCodex、アーキテクチャ設計はClaude Codeという使い分けが現実的です。 ### ベンチマークのスコアで比較できますか？ **直接は比較できません。**Terminal-Bench 2.0とSWE-bench Proは別のベンチマークで、測っている対象が異なります。同じ条件での盲目評価のほうが比較としては直接的です。 ### コストはどのくらい違いますか？ **Express.jsのリファクタリングという同一タスクで、約$15対約$155という比較例があります。**約1/10です。ただし2026年4月2日にAPIトークン単位課金へ変更されたため、キャッシュ活用（75%割引）の影響が大きくなっています。 ### Computer Useは実用的ですか？ **画面を「見ながら」コード生成できる点は画期的ですが、誤操作リスクがあります。**本番環境での利用は慎重に判断すべきです。 ## まとめ - **速度240+トークン/秒（約2.5倍）、同タスクのコスト約1/10**——速度とコストではCodexが圧倒的 - **コード品質の盲目評価は25%対67%**で逆転。複雑なアーキテクチャ作業には不向き - **ベンチマークは測る対象が違えば比較できない。**Terminal-BenchとSWE-benchを並べて優劣は語れない - **Computer Useが差別化要素。**ただし誤操作リスクがあり本番利用は慎重に - **2026年4月2日にAPIトークン単位課金へ移行。**キャッシュ活用（75%割引）の重要性が上昇 - 使い分けは**速度・コスト重視の繰り返しタスク→Codex、品質重視の設計作業→Claude Code** AIツールの選定では、公開されている数値をそのまま並べても判断できません。何を測った数値かを確認したうえで、自分の用途でどの軸が効くかを決める必要があります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAIツール選定・導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## CodexとClaude Codeの住み分けを決める｜LP制作が3日から1日になった2週間の検証 - URL: https://ai-katsu.jp/articles/codex-workflow-2026may - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-28T00:00:00+00:00 - Models: OpenAI Codex, Claude Code - Tools: Figma, GitHub - Tasks: 業務自動化・ワークフロー, ツール検証 > 2026年4月アップデート後のCodex Desktopを2週間使い込み、コーディング・LP制作・デザインモックそれぞれで最適なツールを確定させました。In-appブラウザによるブラウザ内コメント修正でLP制作工数は体感1/5、並列エージェントで朝20分に3〜4タスクが承認待ちへ。長文推論と大規模コードベースはClaude継続という結論です。 AIコーディングツールの比較は、たいていコード生成の精度で語られます。しかし実際の制作現場で効くのは、**ブラウザ確認・画像生成・タスクの並列化まで、どこまで1つの場所で完結するか**です。 この検証では、2026年4月のアップデート後のCodex Desktopを2週間使い込み、Claude Codeとの住み分けを確定させました。**LP制作は従来の3日から1日、FV1本は半日から1時間以内**という結果です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証期間 | 2026年4月16日〜4月28日 | | 対象 | Codex Desktop（OpenAI）／2026年4月アップデート後 | | 比較対象 | Claude Code / Claude Design | | 対象領域 | コーディング／LP・Webサイト制作／デザインモック・ラフ案 | | 結論 | **コーディング・LP・デザインモック領域はCodexを採用。大規模コードベース・長文推論はClaude継続** | > 本記事は自社での検証記録です。所要時間は実案件での実績値および体感値を含みます。 ## 結論：領域ごとに使い分ける | 領域 | 採用ツール | 理由 | | --- | --- | --- | | コーディング全般 | **Codex** | 並列エージェント + GPT-5.5 | | LP・Webサイト制作 | **Codex** | In-appブラウザでブラウザ内コメント修正 | | デザインモック・ラフ案 | **Codex** | 画像生成とコードが同一画面で完結 | | **長文ドキュメント・深い推論** | **Claude** | コンテキスト長・推論品質で依然優位 | 判断のフローに落とすとこうなります。 ``` ターミナル操作が主体 → Claude Code ブラウザ確認 + コード修正を繰り返す → Codex 画像生成が必要 → Codex 複数タスクを並列化したい → Codex 長文ドキュメント / 深い推論 → Claude ``` **この検証で得た本質的な理解は、Codexが「コード生成ツール」ではなく「制作ワークフローの統合プラットフォーム」だという点**です。比較の軸をコード精度に置くと、この差は見えません。 ## 2026年4月に追加された核心機能 | 機能 | 効果 | | --- | --- | | Background computer use | Macアプリを自律操作 | | **In-appブラウザ** | ローカルサーバーをCodex内で直接確認・コメント修正 | | **gpt-image-1.5統合** | コード生成の流れで画像生成→配置まで完結 | | 90以上のプラグイン | Gmail / Drive / Slack / Figma / GitHub 等を横断自動化 | | Skills | 繰り返し作業を再利用可能な指示書としてパッケージ化 | | **GPT-5.5（4/23〜）** | エッジケース対応・テスト品質が顕著に向上 | | メモリ機能（プレビュー） | 個人の好みを記憶し、次回から修正指示が不要に | ## In-appブラウザ：LP制作の工数が体感1/5に この検証で最も効果が大きかった機能です。 操作フローは次のとおりです。 1. Codexアプリ内のブラウザでローカルサーバー（localhost:5173）を開く 2. CTAボタンに**「もう少し大きく・赤系に」とコメントを書き込む** 3. Codexが該当コンポーネントを自動で特定して修正 4. ホットリロードで即反映 結果として次が確認できました。 - **「ブラウザ → コード → ブラウザ」のサイクルが1ウィンドウ内で完結** - **CSSの上書き場所を探す調査工数がほぼゼロ** - ビューポート切替（PC / タブレット / スマホ）もアプリ内で完結 - **LP制作工数が体感で1/5に削減** **フロント開発で時間を食うのは、コードを書くことより「どこを直せばいいか探すこと」です。**画面上の要素を指してコメントできると、この探索が消えます。 ## 並列エージェント：朝20分で3〜4タスクが承認待ちに 各エージェントが独立したGit Worktreeで稼働するため、衝突が起きません。 実際に朝一番で7タスクを同時投入しました。TypeScriptエラー修正、Webhookエンドポイントのスキーマ更新、管理画面のエラーバウンダリ追加、レガシーauth middleware移行、LP追記セクション実装、記事サムネ画像生成＆配置、Gmail未返信問い合わせ抽出＆返信ドラフト作成——といった内容です。 **結果：約20分で4タスクが承認待ちに到達。待ち時間ゼロで、1タスクが詰まっても全体は止まりません。** 運用ルーティンとしてはこうなります。 ``` 1. 朝Codexを起動 2. 5〜7個のタスクをキューに投入（並列実行） 3. コーヒーを淹れる（約20分） 4. 戻ったら3〜4タスクが承認待ちに → まとめて承認 5. 残りタスクは追加情報を提供して再実行 → 午前中でその日の仕事の8割が完了 ``` もうひとつの発見があります。**並列試行には「設計品質」を上げる副作用があります。**設計方針が固まっていない初期段階で「3案並列作成→比較して決定」という使い方をすると、**頭の中だけでは気づけない選択肢が、実装してから見えてきます。** ## 画像生成の統合：FV1本が1時間以内に 従来と比べると工程数が明確に違います。 | | 従来 | Codex | | --- | --- | --- | | 手順 | 画像生成ツール → プロンプト工夫 → ダウンロード → エディタでパス指定 → 表示確認（**5ステップ**） | 「このセクションに画像生成して配置して」→ 生成 → 適切なパスへ配置 → background-image設定まで完結（**1アクション**） | **参考スクリーンショットを渡せば「雰囲気を合わせる」編集も可能**です。コード・画像・スクショが同一画面で循環します。 結果として**FV1本が1時間以内（従来の半日比）**になりました。 ## 実案件での実績 ### プロポーザル資料（HTMLスライド20ページ相当） ``` エージェントA: TailwindCSS + アニメーション付きHTMLスライド実装 エージェントB: Mermaid形式ロードマップ図 + 画像生成で表紙ビジュアル作成 エージェントC: ROI試算Excelシート（グラフ込み）生成 ``` **3エージェント並列で約2時間（従来の丸2日比）。**PRが上がった時点での修正コストも体感3割減（GPT-5.5効果）でした。 ### 新規LP（FV + 4セクション + レスポンシブ対応） - Figmaカンプ → Codex（画像解析）→ ベース実装 → ブラウザ内コメント微調整 - **FV 1本: 1時間以内**（従来の半日比） - **LP全体: 1日**（従来の3日比） - 複数ページはページ別にエージェントを分割して並列処理 営業面での効果も記録しています。**従来はA案・B案を両方作り込むのに2〜3日かかっていたところ、同じ午後中に両方の動くプロトタイプを提示できるようになりました。** ### デザインモック・ラフ案 概要図 + ユーザーフロー図 + 画面モック10枚のドキュメントを**半日（従来の1日半比）**で作成。画面モックをReactコンポーネントとして実装し、**「クリックできる動くモック」として納品**しています。 **静的画像ではなく動くモックを見てもらえると、提案の説得力が変わります。** ## Claude Code との比較 | 観点 | Claude Code | Codex | | --- | --- | --- | | コード単体性能 | ◎ | ◎ 同等水準 | | ターミナル統合 | **◎ 主戦場** | ○ CLIあり | | In-appブラウザ | ✗ なし | **◎ あり** | | 画像生成統合 | ✗ なし | **◎ あり** | | 並列エージェント | △ 限定的 | **◎ Git Worktreesで完全並列** | | プラグイン数 | △ MCP中心 | ◎ 90以上（公式サポート） | | インターフェース | ターミナル | デスクトップアプリ | | 非エンジニアの利用 | ✗ 困難 | **◎ ハードルが低い** | | **コンテキスト長** | **◎ 100万トークン** | △ 400K（Desktopは制限あり） | **Claude Codeが優位な場面**は明確です。ターミナルでのシェル操作が主体の作業、大規模コードベースの理解（100万トークン活用）、長文ドキュメント作成・複雑な推論。 もうひとつ重要な観察があります。**非エンジニア層への普及のボトルネックは「ターミナルというインターフェース」でした。**デスクトップアプリであることが、利用者層を広げます。 ## Claude Design との比較（デザインモック用途） | 観点 | Claude Design | Codex | | --- | --- | --- | | デザイン出力品質 | ◎ | ○ | | **実装への引き継ぎ** | △ 別ツールに渡す | **◎ 同一ツール内で完結** | | ワークフロー統合度 | △ デザインフェーズのみ | **◎ コード・画像・ブラウザが1画面** | | エクスポート先 | Canva / PPTX / HTML | コードとして直接出力 | | 非デザイナー向け | **◎ 橋渡しとして最強** | ○ 実装者が使うツール | **Claude Designが優位なのは**、非エンジニアがデザインを起点にしたい場合、Canva / PPTXへの出力が必要な場合、実装者が別チームの場合です。 **Codexが優位なのは**、デザイン→実装のサイクルを繰り返す現場、1人または少人数で「デザインも実装もやる」ケースです。 ## 導入手順：初日にやること - Codexデスクトップアプリをインストール - GPT-5.5をモデルピッカーで選択 - **慣れているプロジェクトのルートに `AGENTS.md` を作成** - GitHub / Google Drive / Slack / Figma プラグインをインストール・認証 - 小さなタスクを1件実行して感覚を掴む **初日は新規プロジェクトではなく、慣れているプロジェクトで試すこと。**出力の良し悪しを判断できる状態でないと、評価ができません。 `AGENTS.md` の必須記載事項は次の4つです。 ``` # Project Overview（プロジェクト概要） # Coding Conventions（命名規則・ファイル構成） # Common Commands（よく使うコマンド） # Test / Deploy（テスト・デプロイ手順） ``` **コーディング規約が充実しているほど修正コストが下がります。**毎回同じ指摘を繰り返しているなら、それは規約に書くべき内容です。 ## 1週間で習慣化する5機能 1. **並列エージェント実行** — 最初は2個、慣れたら3〜5個 2. **In-appブラウザでのコメント修正** — コードを開かずブラウザ内だけで指示 3. **画像生成との連携** — 画像が必要になったらCodex内で完結させる 4. **Skillsの活用** — 繰り返す作業を `@skill` で呼び出す習慣 5. **メモリ機能の育成** — 修正指示後に「これを覚えておいて」と明示 あわせて、**1週間のうち1日は意図的にCodexを使わない日を作る**という運用を推奨します。生産性の差を対比で実感できるためです。 ## うまくいかなかったこと - **コンテキストウィンドウが400Kに制限されている**（Claude Codeの100万比）ため、大規模コードベースでは不利 - **Codex DesktopのHooksはまだ未実装**（v26.422時点）。CLI版は対応済み - GPT-5.5リリース後に `config.toml` での1M設定が機能しなくなった ## よくある質問 ### Claude CodeとCodex、どちらを使うべきですか？ **用途で分けます。**ブラウザ確認とコード修正を繰り返す作業、画像生成が必要な作業、並列化したい作業はCodex。ターミナル操作が主体の作業、大規模コードベース、長文ドキュメント・深い推論はClaude Codeです。 ### どのくらい速くなりますか？ **この検証では、LP制作が従来の3日から1日、FV1本が半日から1時間以内、プロポーザル資料が丸2日から約2時間でした。**いずれも並列エージェントとIn-appブラウザの効果が大きい領域です。 ### 非エンジニアでも使えますか？ **デスクトップアプリである点がハードルを大きく下げています。**非エンジニア層への普及のボトルネックは、ターミナルというインターフェースでした。 ### 大規模なコードベースでも使えますか？ **コンテキストが400Kに制限されているため不利です。**大規模コードベースの理解が必要な場面では、100万トークンを扱えるClaude Codeのほうが適しています。 ## まとめ - Codexの本質は**「コード生成ツール」ではなく「制作ワークフローの統合プラットフォーム」** - **In-appブラウザが決定打。**「どこを直せばいいか探す」工数が消え、LP制作は体感1/5に - **並列エージェント（Git Worktrees）で朝20分に3〜4タスクが承認待ちへ。**並列試行には設計品質を上げる副作用もある - 画像生成の統合で**FV 1本が1時間以内（従来の半日比）** - **長文ドキュメント・深い推論・大規模コードベースはClaudeが依然優位**（コンテキスト400K vs 100万） - **AGENTS.mdの規約が充実するほど修正コストが下がる** ツール選定は「どちらが優れているか」ではなく「どの工程を短縮したいか」で決まります。工程をまたぐ移動が多い作業ほど、統合された環境の効果が出ます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の制作・開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIエージェントからLINEに送る｜LINE Bot MCP Serverの導入と詰まりどころ - URL: https://ai-katsu.jp/articles/line-bot-mcp-server - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-27T00:00:00+00:00 - Models: Claude - Tools: LINE, MCP - Tasks: 開発・エンジニアリング, ツール検証 > LINE公式が提供するMCPサーバーを設定し、テキストメッセージとFlexメッセージの送信を確認しました。初期設定は1〜2時間程度。Windowsでビルドが失敗する原因（package.jsonのrm -rf）と3つの回避策、Channel Access Tokenの管理方法までをまとめています。 AIエージェントに実務を任せようとすると、最後は「通知をどう届けるか」に行き着きます。国内の顧客接点としてLINEを使っているなら、そこに直接投げられるかが実用性を決めます。 この検証では、LINE公式が提供する**LINE Bot MCP Server**を設定し、**テキストメッセージとFlexメッセージの送信がともに動作すること**を確認しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月27日〜（検証中） | | 対象 | LINE Bot MCP Server（`@line/line-bot-mcp-server`）／Preview版 | | 提供元 | LINE株式会社（公式） | | やりたかったこと | Claude Code（MCP）からLINEメッセージを送信し、通知・配信をAIエージェントから直接操作できるようにする | | 結果 | **テキスト（push\_text\_message）・Flex（push\_flex\_message）ともに送信成功** | | 導入コスト | 初期設定 **1〜2時間程度**／学習 **30分程度**／費用 無料 | | 判定 | **条件付きで導入可**（Preview版のため本番利用は慎重に） | ## 結論：3つのツールだけだが、通知用途には足りる 提供されているツールはシンプルです。 | ツール | 内容 | 結果 | | --- | --- | --- | | `push_text_message` | ユーザーへのテキストメッセージ送信 | **動作確認済み** | | `push_flex_message` | リッチフォーマットのFlexメッセージ送信 | **動作確認済み** | | `get_profile` | ユーザープロフィール情報の取得 | — | できるのは**push送信のみで、incoming webhook等は対象外**です。つまり「AIから送る」ことはできますが、「ユーザーからの受信をトリガーにする」用途は範囲外になります。 それでも**通知の自動送信という目的には十分**です。処理が終わったらLINEで知らせる、といったワークフローがそのまま組めます。 ## Flexメッセージが送れる意味 テキストだけでなく**Flexメッセージ（リッチなカードUI）も正常にレンダリングされることを確認**しました。 通知の質は、届く速さだけでなく**読んだ瞬間に判断できるか**で決まります。テキストの羅列より、構造化されたカードのほうが情報を追いやすくなります。 AIがFlexメッセージ用JSONを生成できれば、**内容に応じてレイアウトごと変えられます。**定型の通知テンプレートを人が用意する必要がなくなります。 ## セットアップの流れ 1. LINE Developers ConsoleからChannel Access TokenとDestination User IDを取得 2. リポジトリをクローンして `npm install` 3. `npm run build` でビルド → distディレクトリ生成 4. Claude Desktopの `claude_desktop_config.json` にMCPサーバーを登録 5. Claudeから各ツールを呼び出して送信を確認 Claude Codeでも同様の設定で動作します。**Claude Desktopからの設定はconfig.jsonへの記述のみでシンプル**でした。 ## Windowsでビルドが通らない（と対処法） この検証で最も実用的な発見です。参考にした解説記事はLinux/macOS向けのため、**Windowsで手順通り進めるとビルドエラーになります。** ``` 'rm' は、内部コマンドまたは外部コマンド、 操作可能なプログラムまたはバッチ ファイルとして認識されていません。 ``` **原因は `package.json` の `clean` スクリプトにUnix系コマンド `rm -rf` が使われていること**です。`build` スクリプトが内部で `clean` を呼び出すため、ビルド全体が失敗します。 ``` "clean": "rm -rf dist/*", "build": "npm run format:check && npm run typecheck:test && npm run clean && tsc && shx chmod +x dist/*.js" ``` 対処法は3つあります。 | 対処法 | 方法 | | --- | --- | | **① rimrafを使う（推奨）** | `npm install --save-dev rimraf` → `"clean": "rimraf dist/*"` に書き換え | | ② PowerShellで手動削除 | `Remove-Item -Recurse -Force dist\*` の後に `npx tsc` | | **③ Dockerを使う（ビルド不要）** | `docker pull ghcr.io/line/line-bot-mcp-server` | **OSSツールの導入では、解説記事のOS前提を確認しておくと詰まりません。**ビルドスクリプトにOS依存のコマンドが入っているケースは珍しくありません。 ## トークン管理の注意点 セキュリティ面で押さえるべき点です。 - **Channel Access Tokenが漏洩するとメッセージ送信が可能になるため、厳重な管理が必要** - **configファイルへのハードコードは避け、環境変数で管理する** - **Destination User IDは個人を特定する情報**のため、取り扱いに注意 AIエージェントに外部サービスを操作させる構成では、**認証情報がどこに置かれるかを必ず確認する**必要があります。設定ファイルは共有・バックアップされやすい場所です。 ## 懸念点 - **Preview版のため仕様変更リスクがある**（実験的目的向けと位置づけられている） - Node.js v20以上が必要 - push送信のみで、受信をトリガーにする用途は範囲外 - LINE Messaging APIに依存するため、LINE側の仕様変更の影響を受ける ## 次に見ているもの：LINEマーケティング周りのMCP この領域では他にもMCP対応が進んでいます。 | ツール | 状況 | 概要 | | --- | --- | --- | | **UTAGE MCP** | MCP対応済み | ファネル・LP・配信管理をAIから直接操作可能。**接続URLを登録して認証するだけで使える** | | Lメッセージ MCP | 要調査 | LINE配信ツールのMCP連携 | 組み合わせの可能性として、**LINE Bot MCPで個別通知 × UTAGE MCPでファネル・シナリオ管理**という構成が考えられます。個別の通知と配信設計を、どちらもAIから操作できる形です。 ## よくある質問 ### 何ができますか？ **テキストメッセージ送信・Flexメッセージ送信・プロフィール取得の3つです。**push送信のみで、受信をトリガーにする用途は対象外です。 ### 費用はかかりますか？ **MCPサーバー自体は無料です。**LINE Messaging APIの送信数に応じた従量課金があり、無料枠を超えた分は有料になります。 ### Windowsでビルドが失敗します **`package.json` の `clean` スクリプトに `rm -rf` が使われているためです。**rimrafに置き換えるか、公式Dockerイメージを使ってビルドをスキップしてください。 ### 本番運用できますか？ **Preview版のため慎重な判断が必要です。**動作自体は確認できていますが、仕様変更リスクがあります。 ## まとめ - LINE公式提供のMCPサーバーで、**テキスト・Flexメッセージともに送信成功** - ツールは3つ（`push_text_message` / `push_flex_message` / `get_profile`）と**シンプルだが通知用途には十分** - **Flexメッセージが送れると、通知の内容に応じてレイアウトごと変えられる** - **Windowsではビルドが失敗する。**rimrafへの置き換えかDocker利用で回避 - **Channel Access Tokenは環境変数で管理**。configファイルへのハードコードは避ける - Preview版のため**本番導入は仕様安定後が望ましい** AIエージェントの実用性は、最後の「届ける」部分で決まります。既存の顧客接点にそのまま出力できるかを、早い段階で確認しておくと設計が楽になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Codex Desktopのサブエージェントとhooksを検証｜設定が静かに無視される罠 - URL: https://ai-katsu.jp/articles/codex-desktop-subagents-hooks - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-27T00:00:00+00:00 - Models: OpenAI Codex, Claude Code - Tools: MCP - Tasks: 開発・エンジニアリング, ツール検証 > Codex Desktopでサブエージェントとhooksを設定し、動くもの・動かないものを切り分けました。サブエージェントは.codex/agents/にtomlを置くだけで動作、一方hooksはv26.422では未実装で設定がエラーなく無視されます。あわせてコンテキストウィンドウが経路によって1M→400K→実効258Kと変わる事実も記録しています。 AIコーディングツールを比較するとき、チャットの精度だけを見ると判断を誤ります。**自動化・並列化の仕組みがあるか**で、実務での使い方が変わるためです。 この検証では、Codex Desktopの**サブエージェント**と**Hooks**を実際に設定し、動くもの・動かないものを切り分けました。あわせて**コンテキストウィンドウが経路によって大きく違う**という事実も確認しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年4月27日 | | 対象 | Codex Desktop（OpenAI）v26.422.30944（macOS） | | 検証内容 | サブエージェント機能・Hooks機能 | | 結果 | **サブエージェントは動作確認済み／HooksはDesktop v26.422では未実装（設定は静かに無視される）** | | 付随する発見 | **Codexのコンテキストは400Kに制限。CLI実効値は約258,400トークン** | | 状況 | 完了（一部機能は未対応を確認） | ## 結論：サブエージェントは動く、DesktopのHooksは動かない 切り分けた結果はこうです。 | 機能 | 結果 | | --- | --- | | **サブエージェント** | **動作確認済み。**`.codex/agents/` にtomlを置くだけで即認識 | | **Hooks（Desktop）** | **発火せず。**`codex_hooks` フィーチャーキーがv26.422では未実装 | Hooksについて重要なのは、**設定は静かに無視される**という点です。エラーも警告も出ません。 気づけたのは、アプリログの `Features enabled` を確認したためです。 ``` # 実際のログ Features enabled: "enable_request_compression, collaboration_modes, personality, request_rule, fast_mode, image_generation, ..." # → codex_hooks の記載なし ``` **設定を書いたのに動かないとき、ログの有効フィーチャー一覧を見るのが最短の切り分けです。**設定ファイルの書き方を延々と疑う前に、そもそも機能が有効かを確認できます。 ## Claude Codeとの機能対応 | 機能 | Claude Code | Codex Desktop/CLI | | --- | --- | --- | | サブエージェント | あり（Agentツール） | あり（`.codex/agents/*.toml`） | | Hooks | あり（7イベント） | CLIはあり / **Desktopは未対応**（v26.422） | | MCP統合 | あり | あり（豊富、自身をMCPサーバーに公開も可） | | 設定ファイル | CLAUDE.md | AGENTS.md（**形式非互換**） | | パーミッションモード | 3段階 | 3段階（**OSサンドボックスが強み**） | | GitHub Action | なし（公式） | あり（公式サポート） | | スラッシュコマンド | あり | あり（`/review` `/diff` `/compact` 等） | 設定ファイルの**形式が非互換**である点は、両方を使う場合に効いてきます。同じ内容を2つの形式で維持することになります。 ## サブエージェント：tomlを置くだけ 設定は単純です。プロジェクト配下の `.codex/agents/` に `.toml` ファイルを置くだけで認識されます。**`config.toml` への追記は不要**です。 ``` name = "code-reviewer" description = "Review diffs and report concrete risks before summarizing." developer_instructions = """ You are a review-focused sub-agent. Inspect the diff carefully and report: - correctness bugs - behavioral regressions - security or data-loss risks - missing tests Order findings by severity, cite files and lines when possible. """ model = "gpt-5.4-mini" model_reasoning_effort = "medium" ``` プロジェクトを `trust_level = "trusted"` に設定していれば即時認識され、デスクトップUIからスレッドとして呼び出せます。 特徴は**エージェントごとにモデル・推論レベル・MCPサーバーをオーバーライドできる**点です。レビュー用は軽量モデル、設計用は高性能モデルといった使い分けができます。 ## Hooks：書き方の落とし穴 Desktopでは発火しませんでしたが、設定の書き方自体には確認できた点があります。 ``` [features] codex_hooks = true [[hooks.PreToolUse]] command = "/path/to/scripts/security-check.sh" ``` **書き方の注意点** - **`[hooks.PreToolUse]`（単一テーブル）はエラー。`[[hooks.PreToolUse]]`（配列テーブル）が正しい** - **`matcher = { tool_name = "bash" }` はエラー。`matcher = "bash"` の文字列形式が正しい** - **スクリプトを置くだけでは動作しない。必ず `config.toml` への登録が必要** イベントは**6種類で固定**です。 | イベント | タイミング | | --- | --- | | `SessionStart` | セッション開始時 | | `PreToolUse` | ツール実行直前 | | `PostToolUse` | ツール実行直後 | | `PermissionRequest` | 承認要求前 | | `UserPromptSubmit` | プロンプト送信時 | | `Stop` | 会話終了時 | イベント種類はプラットフォーム固定でユーザーによる追加・変更は不可ですが、**1つのイベントに複数スクリプトを設定でき、各スクリプトに `matcher` で実行条件を絞り込めます。** ## コンテキストウィンドウは経路で変わる この検証で最も実務的な発見です。 | アクセス経路 | GPT-5.4 | GPT-5.5 | gpt-5.4-mini | | --- | --- | --- | --- | | API | 1,050,000 | 1,050,000 | 400,000 | | ChatGPT（ブラウザ/アプリ） | 1,050,000 | 1,050,000 | 400,000 | | **Codex Desktop** | **400,000** | **400,000** | — | | Codex CLI（公称） | 400,000 | 400,000 | — | | **Codex CLI（実効値）** | **約258,400** | **約258,400** | — | ポイントは3つあります。 **① Codexは上限が400Kに制限されている**——APIやChatGPTでは1,050,000トークン使えますが、Codex Desktop・CLIはモデル仕様の約1/3に絞られています。 **② CLIの実効値はさらに低い（既知のバグ）**——CLIが「272K入力 + 128K出力 = 400K」という分割値を誤認し、実際には約258,400トークンしか使えない状態です。修正要求のIssueが上がっています。 **③ GPT-5.5リリース後、1M設定が機能しなくなった**——以前は `config.toml` での1M設定が動いていたケースがありましたが、機能しなくなったとの報告が多数あります。 感覚的に整理するとこうなります。 ``` ChatGPT/API : 1,050,000トークン（本の約800ページ分） Codex Desktop: 400,000トークン（約300ページ分） Codex CLI実効: 258,400トークン（約200ページ分） ``` **「モデルのコンテキスト長」と「そのツールで実際に使える長さ」は別物です。**ツール選定時にはモデル仕様だけを見ても判断できません。 ## だからサブエージェントが要る この2つの発見はつながっています。 **Codexはコンテキストが意図的に絞られているため、大規模プロジェクトほどサブエージェントで分割処理する必要性が高くなります。** ただし、分割の価値はそれだけではありません。 **並列処理の本質は「速さ」だけでなく「各エージェントが迷わず集中できること」です。**コンテキストウィンドウが大きくても並列処理が有効なのは、各エージェントが専用のクリーンなコンテキストで作業できるため品質が上がるからです。 ## ビジネス側への説明 非エンジニアに伝えるなら、次の言い換えが分かりやすくなります。 - **サブエージェント** = 「複数担当者を同時にアサインする感覚」 - **Hooks** = 「AIの行動にコンプライアンス・承認・ログを自動連動させる仕組み」 Hooksは、AIが何かをする前後に自動でスクリプトを走らせる仕組みです。**承認プロセスや監査ログを、人の運用ではなく仕組みで担保できます。** ## よくある質問 ### Codex DesktopでHooksは使えますか？ **v26.422時点では使えません。**`codex_hooks` フィーチャーキーが未実装で、設定は静かに無視されます。アプリログの `Features enabled` に含まれていないことで確認できます。CLI版には実装されています。 ### サブエージェントの設定方法は？ **`.codex/agents/` に `.toml` ファイルを置くだけです。**`config.toml` への追記は不要で、プロジェクトが `trusted` であれば即時認識されます。 ### Hooksの設定でエラーが出ます **`[[hooks.PreToolUse]]` の配列テーブル形式を使ってください。**`[hooks.PreToolUse]`（単一テーブル）はエラーになります。`matcher` も文字列形式（`matcher = "bash"`）が正しい書き方です。 ### Codexのコンテキストは1Mではないのですか？ **APIやChatGPT経由では1,050,000トークンですが、Codex Desktop・CLIは400Kに制限されています。**さらにCLIは既知のバグにより実効値が約258,400トークンにとどまります。 ## まとめ - サブエージェントは**`.codex/agents/` にtomlを置くだけで動作**。モデル・推論レベルをエージェント単位で指定できる - **Desktop v26.422ではHooksが未実装。**設定はエラーなく静かに無視される - 動かないときは**ログの `Features enabled` を確認**するのが最短の切り分け - Hooksの書き方は**`[[hooks.PreToolUse]]` の配列テーブル形式**、`matcher` は文字列形式 - **Codexのコンテキストは400K（CLI実効値は約258,400）。**モデル仕様の1Mとは異なる - 並列処理の価値は速さだけでなく**各エージェントがクリーンなコンテキストで集中できること** ツールの機能表と実際に動くものは一致しないことがあります。導入判断の前に、使いたい機能が本当に有効かを確認しておくと手戻りが減ります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIは動画を「見ずに読む」｜Video Useが音声トランスクリプトで編集を自動化する仕組み - URL: https://ai-katsu.jp/articles/video-use - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-20T00:00:00+00:00 - Models: Claude Code - Tools: ElevenLabs, Remotion - Tasks: 資料作成・デザイン, ツール検証 > Claude Codeのスキルとして動作する動画編集自動化ツール「Video Use」を調査しました。LLMは映像を直接見ず、単語レベルタイムスタンプ付きの音声トランスクリプトで「読む」設計。フィラー除去・字幕焼き込み・カラグレを自然言語で指示でき、レンダリング後に最大3回まで自己修正する検証ループを備えています。 AIに動画を編集させると聞くと、映像を「見て」判断していると思いがちです。しかしVideo Useの設計はそうではありません。 **LLMは映像を直接「見ない」。音声トランスクリプトで「読む」。**この割り切りが、単語単位の精密なカットを可能にしています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 調査日 | 2026年4月20日 | | 対象 | Video Use（browser-use/video-use）／2026年4月17日前後リリース | | やりたかったこと | Claude Codeを使って動画編集をどこまで自動化できるかを把握する | | 実現すること | **「生の映像フォルダ → Claude Codeにチャット → `edit/final.mp4`」** | | 状況 | **リサーチのみ実施。実際のセットアップ・動作検証は未着手** | | 判定 | **追加検証が必要** | > 本記事はリサーチ段階の記録です。実機での動作確認は未実施のため、品質・処理時間・コストの実測値は含みません。 ## 結論：音声で読むから、単語境界で切れる この設計の意味を整理します。 動画編集の自動化で難しいのは「どこで切るか」です。映像フレームを解析する方式では、フレーム単位の判断になります。しかし**話し言葉のカットで必要なのは「単語の切れ目」**です。 Video Useは2層構造でこれを解決しています。 1. **第1層（必須）**: ElevenLabs Scribe APIによる音声トランスクリプト（**単語レベルタイムスタンプ・話者分離**） 2. **第2層（任意）**: 必要時の静的フレーム合成 **単語レベルのタイムスタンプがあれば、「えーと」の始まりと終わりを正確に指定できます。**映像を見なくても、切る位置は決まります。 裏を返せば制約もあります。**音声依存のため、映像のみの情報（テロップ等）は処理できません。** ## 処理パイプライン ``` Transcribe（ElevenLabs Scribe） → Pack（音声+ビジュアルをLLMが読める形式に圧縮） → LLM Reasoning（EDL生成） → Render（FFmpeg） → Self-Evaluation（最大3回自動修正） → edit/final.mp4 出力 ``` 注目すべきは**Pack**と**Self-Evaluation**です。 Packは「LLMが読める形式に圧縮する」工程です。**大量のトランスクリプトをそのまま渡すのではなく、判断に必要な形に整えてから渡す**——AIに長い素材を扱わせる際の基本形です。 ## 自動検証ループ：レンダリング後に自分でチェックする 実用性を左右する仕組みです。 **レンダリング後に映像ジャンプ・音声ポップ・字幕埋め込みを自己チェックし、最大3回まで自動修正します。** 動画編集の失敗は、出力してみないと分かりません。カット位置がずれていれば映像が飛び、フェードが足りなければポップノイズが入ります。**生成したものを自分で確認して直す経路があるかどうかで、実用性が変わります。** ## 主要機能 - **フィラーワード除去** — 「えーと」「uh」「umm」、無音、言い直しを自動カット - **自動カラーグレーディング** — warm cinematic / neutral punch などをセグメント別に適用 - **オーディオフェード** — **カット箇所に30msフェード挿入**（ポップノイズ防止） - **字幕焼き込み** — カスタムスタイル対応（デフォルト：2-word大文字チャンク形式） - **アニメーションオーバーレイ** — Manim / Remotion / PIL を使ったグラフィック並列生成 - **プロジェクトメモリ** — `project.md` に編集履歴を永続化し、続きから再開可能 細かいところでは**30msフェード**が実務的です。カットしただけではプツッというノイズが入ります。この処理を自動で挟むかどうかは、仕上がりの印象に直結します。 ## 使い方 ``` cd /path/to/raw-footage claude # 例：「edit these into a launch video」 # 例：「フィラーワードを除去して字幕を焼き込んで」 ``` **プリセットやメニュー操作は不要で、自然言語のみで編集指示が完結します。**Claude Codeのスキルとして動作するため、`~/.claude/skills/video-use` にシンボリックリンクを張って組み込みます。 ## 前提条件 - **ElevenLabs APIキーが必須**（別途取得・課金） - FFmpegのインストールが必要（`brew install ffmpeg`） - **Claude Codeのスキルとして動作**（独立したPython SDK/APIは未提供） ## 懸念点 - **ElevenLabs Scribeへの外部API依存**（コスト・可用性リスク） - **コミット数7件と極めて初期フェーズ**。本番利用には不安定な可能性があり、破壊的変更が頻発するおそれ - 独立したAPI/SDKがなく、**Claude Code以外からの利用は想定外** - ライセンスファイルの明示的な記載が未確認 - **音声依存のため、映像のみの情報は処理不可** ## 市場の位置づけ この分野への注目度も記録しておきます。 - 提供元はBrowser Use（Y Combinator W25採択、2025年3月に$17Mシードラウンド調達） - リポジトリは**スター1,600+** - **a16zが「2026年をエージェント動画編集元年」と位置付けている** また、提供元は**「browser-use」→「workflow-use」→「macOS-use」→「video-use」とユースケースを拡張**しています。ブラウザ操作で培った「AIに操作させる」設計を、対象を変えて展開している形です。 ## 次に確認すべきこと 実機検証では、特に日本語対応が焦点になります。 - **日本語音声のトランスクリプト精度**（日本語フィラー「えーと」「あのー」の除去精度） - **1分の動画処理にかかる時間とAPIコスト** - 字幕焼き込みの日本語対応 - Remotionとの連携によるアニメーションオーバーレイの実用性 ## よくある質問 ### AIは映像を見て編集しているのですか？ **直接は見ていません。**ElevenLabs Scribe APIによる音声トランスクリプト（単語レベルタイムスタンプ・話者分離）を「読む」設計です。必要時のみ静的フレームを合成して補います。 ### なぜ音声ベースなのですか？ **単語境界で精密にカットできるためです。**話し言葉の編集で必要なのは単語の切れ目であり、単語レベルのタイムスタンプがあれば映像を見ずに切る位置が決まります。 ### 無料で使えますか？ **Video Use本体はOSSで無料ですが、ElevenLabs APIキーが必須です。**Scribe APIの従量課金とClaude Codeの利用料が別途かかります。 ### 本番運用できますか？ **現時点では慎重に判断すべきです。**コミット数7件と極めて初期フェーズであり、破壊的変更が頻発する可能性があります。 ## まとめ - **LLMは映像を直接見ず、音声トランスクリプトで「読む」**。単語レベルのタイムスタンプが精密カットを可能にする - パイプラインは**Transcribe → Pack → LLM Reasoning → Render → Self-Evaluation** - **レンダリング後に自己チェックし最大3回まで自動修正**する検証ループを内蔵 - フィラー除去・字幕焼き込み・カラグレを**自然言語のみで指示できる** - 制約は**ElevenLabs Scribeへの依存**と**映像のみの情報は処理できない**こと - **コミット数7件の初期フェーズ**。本番利用は安定化を待つべき AIに何かを判断させるとき、扱いやすい形のデータに落としてから渡すと精度が上がります。動画を音声として読む設計は、その一例です。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のコンテンツ制作へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIにアーキテクチャ図を描かせる｜python-pptxで70点精度を出す制約設計 - URL: https://ai-katsu.jp/articles/pptx-architecture-diagram-ai-generation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-20T00:00:00+00:00 - Models: Claude Code - Tools: Google Stitch - Tasks: 資料作成・デザイン, ツール検証 > DBシリンダ・太矢印・クラウドアイコンを含むPowerPointのアーキテクチャ図を、AIエージェントで自動生成するための設計をまとめました。精度を決めるのは「Do's and Don'tsの明示」と「EMU座標のゾーン定義」。AIに座標を計算させず参照させる仕組みと、DESIGN.md／SKILL.mdの三層構造を解説しています。 AIにPowerPointのアーキテクチャ図を作らせようとすると、たいてい図形が重なり、色がばらつき、そもそも意図した形が出てきません。 この検証では、その原因と対策を整理しました。核心は**「AIに座標を計算させず、参照させる」**という設計です。**ピクセルパーフェクトは期待できませんが、正しい制約定義で70点精度は達成可能**という見立てです。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 作成日 | 2026年4月20日 | | 目的 | IT系アーキテクチャ図解スライド（DBシリンダ・太矢印・AWS/Azureアイコン）をAIエージェントで**70点精度**で自動生成する | | 主要技術 | python-pptx / DESIGN.md / SKILL.md / draw.io / Claude Code | | 推奨構成 | **DESIGN.md（方針）＋ トークンJSON（値の正本）＋ SKILL.md（タスク固有の制約）**の三層構造 | | 状況 | リサーチ完了・実装待ち | ## 結論：精度を決めるのは「禁止事項」と「座標の与え方」 この検証で特定した、精度向上の最大要因は2つです。 **Do's and Don'ts の明示と、EMU座標のゾーン定義。** AIに図を作らせるとき、「こういう図を作って」だけでは制御できません。**座標を自分で計算させると、必ずずれます。**あらかじめ配置可能な領域を定数として与え、そこから選ばせる形にすると精度が安定します。 同様に、禁止事項を書くほうが効きます。「テキストのみのスライドを作らない」「3色以上使わない」「図形をオーバーラップさせない」——**やってほしいことより、やってほしくないことを明示するほうが出力のばらつきが減ります。** ## 三層構造：どこに何を書くか ``` DESIGN.md ← ブランド哲学・カラー・フォントの方針 + トークン JSON ← 実際の hex 値・pt 値の正本 + SKILL.md ← タスク固有の制約（EMU座標・禁止事項） ``` 役割分担を整理するとこうなります。 | ファイル | 役割 | 内容例 | | --- | --- | --- | | `CLAUDE.md` | **実装の方法**を伝える | コミット規約・禁止操作・言語設定 | | `DESIGN.md` | **見た目の方針**を伝える | カラー・フォント・レイアウト原則 | | `SKILL.md` | **タスク固有の制約**を伝える | EMU座標・図形種別・検証コマンド | **1つのファイルに全部書くと肥大化し、逆に精度が下がります。**方針・値・制約を分けておくと、それぞれを独立して更新できます。 ## DESIGN.mdとは 2026年3月にGoogle Stitchが提唱した、デザインシステムのMarkdown表現フォーマットです。 - `README.md` がプロジェクト説明の標準であるように、**DESIGN.mdはデザイン仕様のAI向け標準** - LLMが高忠実度で読めるMarkdown形式で、カラー・タイポグラフィ・コンポーネント仕様を1ファイルに集約 - **プロジェクトルート（`/DESIGN.md`）に置くだけでClaude Code・Cursorが自動参照** - 関連リポジトリが**公開10日で35,000スターを超え**、Stripe・Vercel・Linear・Notionなど59サービスのDESIGN.mdを収録 ### 書くべき内容・書かない方がいい内容 **書くべき（効果が高い）** - ブランドの視覚的哲学・雰囲気（**AIが迷ったときの判断基準になる**） - カラーは意味的役割（`primary`, `danger`, `muted`）とhex値の組み合わせ - タイポグラフィは「フォント名だけ」でなく「どの場面で使うか」まで - **明示的な禁止事項（Do's and Don'ts）← 最も精度向上に効く** - 実際に出荷済みコードに基づいたルール（理想ではなく実態） **書かない方がいい（精度が下がる・管理コストが増す）** - 全ルールの網羅（**肥大化すると逆効果**） - 他ドキュメントとの重複情報（二重管理はズレを生む） - 具体的な実装コード（SKILL.mdやコンポーネントファイルへ委譲） - 実際の実装と乖離した理想論 ## EMU座標系とゾーン定義 python-pptxの座標は**EMU（English Metric Units）**で管理されます。 ``` 1インチ = 914,400 EMU 1センチ = 360,000 EMU 1ポイント = 12,700 EMU # 16:9 スライドの標準サイズ SLIDE_W = 9_144_000 # 13.33インチ（横） SLIDE_H = 5_143_500 # 7.5インチ（縦） ``` ここで精度向上の核心になるのが**ゾーン定義**です。 | ゾーン名 | left | top | width | height | | --- | --- | --- | --- | --- | | header | 457,200 | 457,200 | 8,229,600 | 685,800 | | main\_left | 457,200 | 1,143,000 | 3,962,400 | 3,200,000 | | main\_right | 4,724,400 | 1,143,000 | 3,962,400 | 3,200,000 | | main\_full | 457,200 | 1,143,000 | 8,229,600 | 3,200,000 | | footer | 457,200 | 4,571,100 | 8,229,600 | 380,000 | この表をSKILL.mdとコードの双方に持たせ、**「必ずこの値を参照すること。座標を自分で計算しない」**と明示します。 ## DBシリンダは「CYLINDER」では作れない 実装上の落とし穴です。 **python-pptxに `CYLINDER` という名称は存在しません。**フローチャート系シェイプで代用します。 | 用途 | 定数名（MSO\_SHAPE） | 値 | | --- | --- | --- | | **DBシリンダ（縦・推奨）** | `FLOW_CHART_MAGNETIC_DISK` | **86** | | DBシリンダ（横） | `FLOW_CHART_DIRECT_ACCESS_STORAGE` | 87 | | テープ型ストレージ | `FLOW_CHART_SEQUENTIAL_ACCESS_STORAGE` | 85 | 太い矢印（Block Arrow）も同様に整数値で指定します。 | 方向 | 定数名 | 値 | | --- | --- | --- | | 右向き | `RIGHT_ARROW` | **33** | | 左向き / 上向き / 下向き | `LEFT_ARROW` / `UP_ARROW` / `DOWN_ARROW` | 34 / 35 / 36 | | 左右双方向 | `LEFT_RIGHT_ARROW` | 37 | | ノッチ付き右矢印 | `NOTCHED_RIGHT_ARROW` | 50 | **使う図形の整数値をSKILL.mdに列挙しておく**ことが、AIに正しい図形を選ばせる条件になります。名前で指示すると、存在しない定数を使おうとします。 ## クラウドアイコンはPNGで埋め込む **python-pptxはSVGネイティブ非対応です。PNG変換が最も安定します。** AWS公式アイコンパックはPNG形式でダウンロード可能です。品質を保ちたい場合は `cairosvg` でSVG→PNG変換してから `add_picture()` に渡します。 ## fix-and-verifyループを組み込む 生成しっぱなしにしないための仕組みです。 1. `template.pptx` を開く 2. `zones.py` のZONES定数を参照して座標を決定 3. 図形・アイコン・テキストを追加 4. **`thumbnail.py` で確認**（LibreOfficeでPPTX→PNG変換して視覚確認） 5. **指摘があれば修正して再確認（ゼロ指摘になるまで繰り返す）** あわせて `validate.py` でXML構造を検証します。**不正なXMLを注入するとPPTXが開けなくなる**ため、保存前の確認が必要です。 **視覚要素の生成では、AI自身が結果を見て直せる経路を作ることが重要です。**出力を見ずに一発で仕上げようとすると、精度は上がりません。 ## アプローチの選び方 ``` 既存PPTXテンプレートがある？ │ ├── Yes → テンプレートPPTX + SKILL.md（EMU座標定義）の組み合わせ │ ↓ │ ブランドカラー・フォントを継承しつつ内容を生成 │ └── No → draw.ioでアーキテクチャを組む ↓ drawio2pptxでPPTXシェイプに変換 ↓ python-pptxでブランドスタイルを後付け適用 ``` 既存テンプレートがある場合は、**スライドを全削除してマスター・テーマだけ残す**方式でベースにします。ブランドの一貫性を保ちつつ、中身だけを生成できます。 ## 70点精度を達成するためのチェックリスト - SKILL.mdに**EMUゾーン定数**を定義してある（AIが座標を計算しない） - 使う図形の**MSO\_SHAPEの整数値**をSKILL.mdに列挙してある - カラーパレットを**RGB値**でSKILL.mdに記載してある - **Do's and Don'tsセクションに禁止事項**を書いてある - `thumbnail.py` / `validate.py` による**fix-and-verifyループ**を組み込んでいる - クラウドアイコンは**PNG形式**で配置してある - テンプレートPPTXを使う場合は**スライドマスターを確認**してある ## よくあるハマりポイント | 問題 | 原因 | 対処 | | --- | --- | --- | | SVGが埋め込めない | python-pptxがSVG非対応 | PNGに変換してから `add_picture()` | | 図形が重なる | EMU計算ミス | **ZONES定数を参照する仕組みにする** | | DBシリンダが見つからない | `CYLINDER` という名前が存在しない | **値86**（FLOW\_CHART\_MAGNETIC\_DISK）を使う | | テーマカラーが引き継がれない | テンプレートのマスターが参照されていない | `prs.slide_layouts[6]` で空白レイアウトを使う | | PPTXが開けなくなる | 不正なXMLを注入した | `validate.py` で確認してから保存 | | グループ化できない | python-pptxにグループ化APIがない | XML直接操作か、座標をハードコードで回避 | ## よくある質問 ### AIでどこまでの品質が出せますか？ **ピクセルパーフェクトは期待できませんが、正しい設計と制約定義で70点精度は達成可能という見立てです。**最大の要因はDo's and Don'tsの明示とEMU座標のゾーン定義です。 ### なぜ座標をAIに計算させてはいけないのですか？ **計算させると図形が重なるなどのずれが発生するためです。**あらかじめゾーンを定数として定義し、AIには参照させる形にすると精度が大幅に向上します。 ### DESIGN.mdとCLAUDE.mdはどう使い分けますか？ **CLAUDE.mdは実装の方法、DESIGN.mdは見た目の方針、SKILL.mdはタスク固有の制約です。**1ファイルに全部書くと肥大化して逆効果になります。 ### クラウドサービスのアイコンはどう入れますか？ **PNG形式で埋め込みます。**python-pptxはSVGネイティブ非対応のため、SVGしかない場合は `cairosvg` 等で変換してください。 ## まとめ - 精度を決めるのは**Do's and Don'tsの明示とEMU座標のゾーン定義**。この2つで70点精度が狙える - **AIに座標を計算させず、定数を参照させる**。図形の整数値も列挙しておく - 構成は**DESIGN.md（方針）＋トークンJSON（値）＋SKILL.md（制約）の三層**。1ファイルに詰め込まない - DESIGN.mdは**プロジェクトルートに置くだけでAIツールが自動参照**する - **python-pptxに `CYLINDER` は存在しない。**DBシリンダは値86（FLOW\_CHART\_MAGNETIC\_DISK） - **SVGは非対応。PNGに変換して埋め込む** - **thumbnail.py / validate.py によるfix-and-verifyループ**を組み込み、AI自身が結果を見て直せるようにする AIに視覚要素を作らせるときは、自由度を上げるほど品質が下がります。選択肢を絞り、確認と修正の経路を用意することが、実用水準への近道になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の資料作成業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Microsoft Copilotの料金プランを整理する｜個人・法人でどこまで無料で使えるか - URL: https://ai-katsu.jp/articles/microsoft-copilot-pricing - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-20T00:00:00+00:00 - Models: Microsoft Copilot - Tools: Excel - Tasks: リサーチ・データ収集, ツール検証 > Copilot Pro廃止後の現行プラン体系を、個人向け・法人向けそれぞれ整理しました。法人はベースプランにCopilotが含まれず「アドオンとの2階建て」になる点、2026年4月15日の仕様変更でエンタープライズのOffice内Copilot Chatが廃止された点、キャンペーン価格の期限までをまとめています（2026年4月20日時点の情報）。 Microsoft Copilotの料金プランは、Copilot Proの廃止と再編で体系が複雑になりました。「Officeアプリでも使いたい」と思ったとき、**どのプランが必要なのかが分かりにくい**状態です。 この調査では、個人向け・法人向けそれぞれのプラン体系と、**2026年4月15日の仕様変更**の影響を整理しました。 ## この調査の概要 | 項目 | 内容 | | --- | --- | | 調査時期 | 2026年4月20日 | | 対象 | Microsoft Copilot（個人・法人向けプラン） | | やりたかったこと | Copilot Chat単体の無料利用と有料プランで何が変わるかを整理し、用途・規模に合った最小コストプランを選定できるようにする | | 方法 | 公式サイト情報・報道情報による情報収集（実機検証は未実施） | | 判定 | **条件付きで導入可**（用途・コストに応じてプランを選択） | > 本記事の料金・仕様は**2026年4月20日時点**の情報です。Microsoftのプラン変更により変動する可能性があります。最新情報は公式サイトでご確認ください。 ## 結論：用途で3つに分かれる 選定の判断はシンプルです。 | 用途 | 必要なプラン | | --- | --- | | チャットのみ | **無料で十分、課金不要** | | Officeアプリと組み合わせたい（最小コスト） | **Microsoft 365 Personal（¥2,130/月）** | | 高度なAIエージェント・Deep Research等も使いたい | **Microsoft 365 Premium（¥3,200/月）** | **無料のCopilot Chatでも、基本的なAIチャット・画像生成・Web検索は利用可能です。**まず無料で試し、Office内で使いたくなった段階で課金を検討するのが無駄がありません。 ## 個人向け料金プラン（2026年4月時点） | プラン | 月払い | 年払い | 主な内容 | | --- | --- | --- | --- | | 無料（Copilot Chat） | ¥0 | ¥0 | チャット・画像生成（制限あり）・Web検索 | | Microsoft 365 Personal | ¥2,130 | ¥21,300 | 1人用・1TBストレージ・基本Copilot＋Officeアプリ | | Microsoft 365 Family | ¥2,740 | ¥27,400 | 最大6人共有・6TBストレージ（**AI機能は契約者本人のみ**） | | Microsoft 365 Premium | ¥3,200 | ¥32,000 | フルCopilot機能＋高度AIエージェント（旧Copilot Pro相当） | 注意すべきは**Family**です。**最大6人で共有できますが、AI機能は契約者本人のみという制限があります。**家族でAIを使いたい目的では選択肢になりません。 ## Copilot Proは廃止されている 体系が分かりにくくなった原因がこれです。 **Copilot Proは2025年に廃止され、「Microsoft 365 Premium」に統合済みです。単体での新規購入はできません。** 加えて、**2026年3月以降、Microsoft 365 PersonalユーザーもCopilot Chat経由でWord/Excel/PowerPointエージェントが順次使えるようになり、PremiumとPersonalの差は縮まっています。**ただしデスクトップOfficeでのフル活用にはPremiumが推奨されます。 ## Office系アプリでCopilotを使う条件 | 使いたい機能 | 必要なプラン | | --- | --- | | Copilot Chat（Web版のみ） | 無料 | | Office内でのCopilot基本機能 | Microsoft 365 Personal以上 | | Word/Excel/PowerPointエージェント（Chat経由） | Microsoft 365 Personal以上（2026年3月〜順次開放） | | デスクトップOfficeでのCopilotフル活用 | Microsoft 365 Premium推奨 | ## 法人向け：ベースプランにCopilotは含まれない ここが法人検討時の最大の落とし穴です。 | プラン | 月額換算（年払い） | Officeアプリ | 対象規模 | | --- | --- | --- | --- | | Business Basic | 約¥750 | Web版のみ | 300ユーザー以下 | | Business Standard | 約¥1,560 | デスクトップ版込み | 300ユーザー以下 | | Business Premium | 約¥2,750 | デスクトップ版＋高度セキュリティ | 300ユーザー以下 | **これらのベースプランにCopilot機能は含まれません。**利用するには別途アドオンが必要です。 | プラン | 月額（ユーザー/月） | 対象規模 | 購入条件 | | --- | --- | --- | --- | | **Copilot Business（キャンペーン ～2026/6/30）** | **¥2,698** | 300ユーザー以下 | Business Basic/Standard/Premium いずれかが必須 | | Copilot Business（通常価格） | ¥3,148 | 300ユーザー以下 | 同上 | | Copilot Business（月払い） | ¥3,778 | 300ユーザー以下 | 同上 | | Microsoft 365 Copilot（大企業向け） | 約¥4,500（$30相当） | 制限なし | Enterprise系ライセンスが必要 | **つまり法人でCopilotを使うには「ベースプラン＋アドオン」の2階建てになります。**Business Standard（約¥1,560）+ Copilot Business（¥2,698）で、1ユーザーあたり月額約¥4,258という計算です。 ## 時期に注意：値上げが控えている - **法人向けCopilot Businessのキャンペーン価格（¥2,698/月）は2026年6月30日まで。**7月以降は¥3,148/月に値上がり予定 - **2026年7月に法人向けベースプラン（Business Basic/Standard）も値上げ予定** **導入時期によって、年間コストが変わります。**検討中の場合はこの期限を織り込む必要があります。 ## 2026年4月15日の仕様変更 法人にとって影響の大きい変更です。 | 組織規模 | 変更内容 | | --- | --- | | **2,000シート以上（エンタープライズ）** | **Word・Excel・PowerPoint・OneNoteでのCopilot Chatが完全廃止。有料ライセンス必須** | | 300〜2,000シート未満 | 「Copilot Chat (Basic)」として機能制限が明示される | | 300シート以下（中小企業） | 「標準アクセス」として一部制限（音声機能非提供・ピーク時制限） | | **個人向け** | **影響なし** | | Outlook | **全組織で引き続き利用可能（例外）** | 注目すべきは最後の行です。**法人向けで唯一、Outlookだけは全組織で無料のまま継続利用可能です**（2026年4月15日以降も）。 **「無料でどこまで使えるか」は、アプリ単位で確認する必要があります。**組織全体で一律ではありません。 ## 無料と有料で何が変わるか（法人） | 機能 | Copilot Chat（無料） | Copilot Business（有料） | | --- | --- | --- | | エンタープライズデータ保護 | あり | あり | | Webベースのチャット | あり | あり | | **社内データ（メール・ファイル）への接続** | なし | **あり** | | Word/Excel/PowerPoint内統合 | 制限あり（4/15以降さらに縮小） | **フル統合** | | **Teams会議の要約・文字起こし** | なし | **あり** | | Outlookのメール要約・下書き | 一部のみ | フル機能 | | カスタムエージェント作成 | なし | **あり** | | 画像生成 | なし | あり | | リクエスト上限 | 約20回/日 | 実質無制限 | **有料版の本質的な価値は「社内データへの接続」です。**メールやファイルを踏まえた回答ができるかどうかが、無料版との決定的な差になります。 汎用的なチャットだけなら無料版や他社サービスでも足ります。**自社のデータを使わせたい場合にのみ、有料ライセンスの意味が出ます。** ## アプリ別にできること（法人・Copilot Business） | アプリ | できること | | --- | --- | | Word | 提案書・議事録・報告書の下書き自動生成、自然言語での文書指示 | | Excel | データ分析・集計を自然言語で指示、関数・条件付き書式のサポート | | PowerPoint | テキスト指示だけでスライド自動生成 | | Teams | 会議の自動要約、次のアクション提示、遅刻参加者へのキャッチアップ | | Outlook | メール自動要約、返信下書き自動生成 | ## 他社サービスとの比較 | 項目 | Microsoft Copilot（Premium） | ChatGPT Plus | Google Gemini Advanced | | --- | --- | --- | --- | | 月額コスト | ¥3,200 | 約¥3,000 | 約¥2,900 | | **Office統合** | **◎** | △（プラグイン経由） | △（Google Workspace連携） | | 無料プランの充実度 | ○ | ○ | ○ | | 日本語対応 | ○ | ◎ | ○ | 価格帯はほぼ横並びです。**差がつくのはOffice統合の深さで、既存のOfficeユーザーには親和性が高くなります。**逆に言えば、Officeを使わない用途では選ぶ理由が薄くなります。 ## よくある質問 ### Copilot Proはまだ買えますか？ **買えません。**2025年に廃止され、Microsoft 365 Premiumに統合されました。 ### ExcelやPowerPointでCopilotを使うには何が必要ですか？ **個人ならMicrosoft 365 Personal（¥2,130/月）以上が必要です。**デスクトップOfficeでのフル活用にはPremium（¥3,200/月）が推奨されます。法人の場合はベースプランに加えてCopilotアドオンが必要です。 ### 法人でCopilotを使う総額はいくらですか？ **ベースプラン＋アドオンの2階建てになります。**Business Standard（約¥1,560）+ Copilot Business（キャンペーン価格¥2,698）で、1ユーザーあたり月額約¥4,258です。ただしキャンペーンは2026年6月30日までで、7月以降は値上がり予定です。 ### 無料版と有料版の一番の違いは？ **社内データ（メール・ファイル）への接続の可否です。**Teams会議の要約やカスタムエージェント作成も有料版のみです。汎用チャットだけなら無料版で足ります。 ## まとめ - 選定基準は3つ。**チャットのみ→無料／Office連携→Personal（¥2,130）／高度なエージェント→Premium（¥3,200）** - **Copilot Proは2025年に廃止**、Microsoft 365 Premiumに統合済み - 法人は**「ベースプラン＋Copilotアドオン」の2階建て**。ベースプランにCopilotは含まれない - **Copilot Businessのキャンペーン価格（¥2,698）は2026年6月30日まで**。7月には値上げ予定 - **2026年4月15日以降、2,000シート以上の組織ではOffice内Copilot Chatが完全廃止。**ただしOutlookは例外的に継続 - 有料版の本質的な価値は**社内データへの接続**。汎用チャットだけなら無料版で足りる AIツールの選定では、機能一覧より「無料でどこまでできるか」を先に把握すると判断が速くなります。そのうえで、自社データを使わせる必要があるかを基準に置くと迷いません。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAIツール選定・導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIでスライドを作るならどのルートか｜Claude Design・PowerPoint・Marpの使い分け - URL: https://ai-katsu.jp/articles/claude-design - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-20T00:00:00+00:00 - Models: Claude - Tools: Marp, MCP - Tasks: 資料作成・デザイン, ツール検証 > 2026年4月17日にリリースされたClaude Designを軸に、法人向けスライドとシステム解説図の作成にどのツールが適しているかを整理しました。Figmaの代替ではなくラピッドプロトタイピング用途という位置づけ、PPTX直接エクスポートとデザインシステム登録の価値、そして品質を上げる「型・ルール・禁則」の3層プロンプト設計をまとめています。 AIでスライドを作る方法は、いまや一つではありません。**用途によって最適なツールが変わります。**そして選び間違えると、出てきたものを直す時間のほうが長くなります。 この検証では、2026年4月17日にリリースされた**Claude Design**を軸に、法人向けスライド・システム解説図の作成にどのルートが適しているかを整理しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月20日〜（検証中） | | 対象 | Claude Design（Anthropic Labs／リサーチプレビュー・2026年4月17日リリース） | | 動力モデル | Claude Opus 4.7 | | やりたかったこと | 法人向けスライド（提案書・決算資料・システム解説図）の作成工数を削減する／矢印・補足情報が多いシステム図をAIで自動生成できるか検証する | | 目標 | スライド初稿作成 数時間 → **30分以内** | | 状況 | **Webリサーチのみ実施。実操作検証は次フェーズ** | | 判定 | **条件付きで導入可**（リサーチ段階の暫定判定） | > 本記事はリサーチ段階の記録です。実際の操作検証は未実施のため、動作品質の実測値は含みません。情報は2026年4月20日時点のものです。 ## 結論：用途別に使うツールが違う リサーチの成果は、この対応表に集約されます。 | シナリオ | 推奨アプローチ | | --- | --- | | 既存PPTXテンプレートあり | Claude for PowerPoint | | ブランド統一スライドを大量生成 | **Claude Design**（デザインシステム登録 → PPTX出力） | | システム解説図・矢印フロー図 | Claude Code + Mermaid MCP（23種類対応） | | 複雑なアーキテクチャ図 | Draw.io XML生成 → インポート | | 決算資料・提案書（品質重視・git管理） | Claude Code + Marp | | 速度重視の叩き台 | **Claude Design** | **「AIでスライドを作る」を一つの手段で解こうとすると、どこかで無理が出ます。**叩き台が欲しいのか、既存テンプレートに沿わせたいのか、システム図を描きたいのか——目的によって適した道具が変わります。 ## Claude Designの位置づけ 業界での評価として定着しつつあるのは、次の見方です。 **Figmaの代替ではなく、ラピッドプロトタイピング（Lovable代替）として位置づけるべき。** リリース時にFigma株が下落するほどの市場インパクトがありましたが、実際の使いどころは異なります。**Figmaレベルの細かいデザイン制御はできません。** | 項目 | Claude Design | Claude for PowerPoint | Claude Code + Marp | Claude Artifacts | | --- | --- | --- | --- | --- | | PPTXエクスポート | ✅ 直接 | ✅ アドイン経由 | △ PDF変換 | ❌ | | デザインシステム統合 | ✅ 自動読み込み | ✅ テンプレート読み取り | ✅ CLAUDE.md | △ | | 対象プラン | Pro以上 | Pro以上 | 全プラン | 全プラン | | git管理 | ❌ | ❌ | ✅ | ❌ | | 品質 | 叩き台レベル | オンブランド | 高品質 | 中程度 | | システム図 | △ | ❌ | ✅ Mermaid | ✅ SVG | ## 法人用途で効く2つの機能 ### ① PPTX直接エクスポート **ArtifactsにはなかったPPTX直接エクスポートに対応しています。**エクスポート形式はPPTX / PDF / スタンドアロンHTML / ZIP / Canva送出です。 法人での資料作成は、最終的にPowerPointで扱われることが多くあります。**既存ワークフローに組み込めるかどうかは、出力形式で決まります。** ### ② デザインシステム登録 **コードベース・デザインファイル・ブランド資料を読み込んで自動適用する機能**です。 これが効くのは、**一度登録すれば以後の全スライドに自動適用される**点です。企業ブランドに沿ったデザインを毎回一から指示する必要がなくなります。 ただし注意点もあります。**デザインシステム登録時にブランドファイル・コードベースをアップロードする必要があり、機密情報の取り扱いに注意が必要です。** ## 品質を上げるプロンプト設計：3層構造 リサーチで見つかった実用的な知見です。**細かい指示なしでは、均質なデザインに寄りやすい**という課題があります。 ``` 層1: 型（構成） → スライド数・セクション順序を明示 層2: ルール → 「1スライド1メッセージ」「タイトル15文字以内」「箇条書き3〜5項目」 層3: 禁則 → 「文字だけスライド禁止」「曖昧表現禁止（検討中等）」「5色以上禁止」 ``` **特に効くのは第3層の禁則です。**「こうしてほしい」だけを伝えると、避けたいパターンが混ざります。「これはするな」を明示するほうが、出力のばらつきが減ります。 あわせて、有効なプロンプト要素として**目的明示・ターゲット指定・枚数指定・出力形式の4要素**が挙げられています。 ## システム解説図はMermaidが有効 矢印や補足情報が多いシステム図については、Claude Designより適した手段があります。 **Mermaid MCP Serverで23種類のダイアグラムが生成可能**で、システム図用途では実用品質という評価です。より複雑なアーキテクチャ図はDraw.io XML生成 → インポートというルートになります。 **図はテキストで書けると強い**——という点も重要です。Mermaidはテキスト形式なので、git管理や差分確認ができます。 ## Claude Code + Marpという選択肢 品質重視・git管理したい場合のルートです。実運用レベルに到達している事例として、次の構成が紹介されています。 ``` rules/（画像プロンプト指針・提案書構成ルール） commands/（カスタムスラッシュコマンド） templates/（Marpテーマ・提案書テンプレート） ``` ポイントは、**固定セクション（契約条項等）はテンプレートから丸コピーを強制し、変更禁止ルールをCLAUDE.mdに記述する**という設計です。 **AIに触らせてはいけない部分を明示する**——法人文書ではこの制約が品質を担保します。生成の自由度を上げるだけでは、実務では使えません。 ## 懸念点 - **リサーチプレビュー段階**のため機能・仕様が変わる可能性がある。本番採用は安定化を待つべき - **Opus 4.7専用のためコストが高い** - 細かい指示なしでは均質なデザインに寄りやすい - **Google Slidesへの直接書き込みは不可**（MCP連携が必要） - Pro以上のプランが必要（Free不可）。設定から有効化も必要 ## よくある質問 ### Claude DesignはFigmaの代替になりますか？ **なりません。**Figmaの代替ではなく、ラピッドプロトタイピング用途という位置づけが業界評価として定着しつつあります。Figmaレベルの細かいデザイン制御はできません。 ### 既存のPowerPointテンプレートがある場合は？ **Claude for PowerPointが最も適合します。**テンプレートを読み取ってオンブランドな出力が得られます。Claude Designはブランド統一スライドの大量生成や、速度重視の叩き台に向いています。 ### システム構成図はどう作りますか？ **Claude Code + Mermaid MCPの組み合わせが実用品質です。**23種類のダイアグラムに対応しています。より複雑なアーキテクチャ図はDraw.io XML生成 → インポートというルートになります。 ### 出力品質を上げるには？ **「型・ルール・禁則」の3層でプロンプトを設計してください。**特に禁則（文字だけスライド禁止、5色以上禁止など）を明示すると、出力のばらつきが減ります。 ## まとめ - AIでのスライド作成は**用途によって最適ツールが違う**。一つの手段で解こうとしない - Claude Designは**Figmaの代替ではなくラピッドプロトタイピング用途**。叩き台の即生成が強み - 法人用途で効くのは**PPTX直接エクスポートとデザインシステムの自動適用** - 品質を上げるには**「型・ルール・禁則」の3層プロンプト設計**。特に禁則が効く - システム解説図は**Claude Code + Mermaid MCP**、複雑な構成図は**Draw.io XML** - 法人文書では**AIに触らせない固定セクションを明示する**設計が品質を担保する - リサーチプレビュー段階のため**本番採用は安定化を待つべき** 資料作成の自動化では、生成の速さより「どこまでを任せるか」の線引きが結果を左右します。用途ごとにルートを決めておくと、毎回の判断が不要になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の資料作成業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Browser Use CLIはComputer Useを置き換えるか｜DOM解析と画面キャプチャの精度差 - URL: https://ai-katsu.jp/articles/browser-use-cli - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-20T00:00:00+00:00 - Models: Claude Code - Tools: Browser Use, Computer Use - Tasks: リサーチ・データ収集, ツール検証 > Google Trendsの調査自動化をComputer UseからBrowser Use CLIへ置き換えられるかを調査しました。WebVoyagerベンチマークで89%（Computer Use 56%）という精度差、Daemonアーキテクチャによる約50msのレイテンシ、既存Chromeプロファイル利用によるアンチボット回避までをまとめています。 AIにブラウザを操作させる方法は、大きく2つに分かれます。**画面をキャプチャして見る**か、**DOMを解析する**かです。 この違いは精度に直結します。Web操作のベンチマークでは、**DOM解析ベースのBrowser Useが89%、画面キャプチャベースのComputer Useが56%**という差が出ています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月20日〜（検証中） | | 対象 | Browser Use CLI（Playwright + DOM解析ベースのブラウザ自動化フレームワーク） | | やりたかったこと | Google Trendsの急上昇キーワード調査を、Computer Useから低コスト・高精度な方式へ置き換える | | 精度 | **WebVoyagerベンチマーク 89%**（Computer Use 56%比で**+33pt**） | | コマンドレイテンシ | **約50ms**（Daemonアーキテクチャによる） | | コスト | **セルフホストなら$0**（クラウド版は$0.05/step） | | 判定 | **条件付きで導入可**（実動作確認後に更新予定） | > 本記事は調査・設計段階の記録です。実際のPoC実施は後日のため、動作結果の数値は掲載していません。 ## 結論：Web操作に限るなら、専用ツールのほうが強い Computer Useはデスクトップ全体を操作できる汎用性があります。しかし**対象がブラウザだけなら、汎用性は必ずしも利点になりません。** | 項目 | Browser Use CLI | Computer Use | pytrends | | --- | --- | --- | --- | | 制御範囲 | ブラウザのみ | デスクトップ全体 | Python API（ブラウザ不要） | | 仕組み | **DOM解析（Playwright）** | 画面キャプチャ（Vision LLM） | 非公式内部API | | モデル依存 | 任意のLLMを選択可 | 特定モデル専用 | モデル不要 | | **精度（WebVoyager）** | **89%** | 56% | N/A | | コスト | 無料（セルフホスト） | トークン従量課金 | 無料 | | JSレンダリング対応 | ◎ 完全対応 | ◎ 完全対応 | × 非対応 | | 既存Chromeプロファイル | ◎ そのまま使用可 | △ 毎回入力 | × | | 安定性リスク | ◯ 公式OSS | ◯ 公式 | △ 非公式・突然壊れる可能性 | **DOM解析ベースのため、JavaScriptレンダリング後の要素も確実に取得できます。**画面を見て判断する方式では、レンダリング結果の見た目に依存します。 ## Daemonアーキテクチャ：毎回起動しない 速度面での特徴です。 **ブラウザプロセスをコマンド間で維持するため、コマンドレイテンシは約50ms**にとどまります。 ブラウザ自動化で意外とコストになるのが起動時間です。1コマンドごとに立ち上げ直していると、連続操作で積み上がります。**プロセスを保持する設計は、複数ステップの操作を前提にした作りです。** ## 3種類のブラウザモード - **ヘッドレスChromium**（デフォルト） - **実際のChrome** — 既存のログイン済みプロファイルをそのまま使用 - **クラウドブラウザ**（リモート） 2つ目が実務では重要です。**ログイン済みサービスへのアクセスが、認証を都度やり直すことなく行えます。**アンチボット検出が強いページでも、実際のプロファイルを使うほうが通りやすくなります。 ``` # 実際の Chrome プロファイルを指定して起動 browser-use --profile /path/to/Chrome/Default open "https://trends.google.com/trending?geo=JP" ``` ## Claude Codeから自然言語で呼ぶ MCPサーバーとして登録できるため、**自然言語1文でブラウザ操作が完結**します。 ``` # インストール curl -fsSL https://browser-use.com/cli/install.sh | bash browser-use doctor # Claude Code に MCP 登録 claude mcp add browser-use -- uvx --from 'browser-use[cli]' browser-use --mcp ``` 登録後は、次のような指示で実行できます。 ``` Google Trendsの急上昇ワード上位20件（日本・今日）を取得して一覧化して ``` CLIから直接操作する場合は次のようになります。 ``` # 1. ページを開く browser-use open "https://trends.google.com/trending?geo=JP" # 2. JS レンダリング完了を確認 browser-use state # 3. テキスト一括取得 browser-use get text # または JavaScript で直接抽出（より確実） browser-use eval " Array.from(document.querySelectorAll('[data-entity-id]')) .map(el => el.innerText.trim()) .slice(0, 20) .join('\n') " ``` 操作コマンドは `click`、`type`、`input`、`scroll`、`hover`、`upload`、`select`、`eval`（JavaScript）、`get html/text` が用意されています。 ## なぜスクレイピングでは取れないのか この検証の対象を例にすると分かりやすくなります。 **Google Trendsの急上昇キーワードページはクライアントサイドJSでデータが描画されるため、`requests` や `curl` では取得できません。**HTMLを取得しても、データがまだ入っていない状態のものが返ります。 **JSレンダリングが必要なページでは、ブラウザを動かすしかありません。**これがスクレイピングライブラリではなくブラウザ自動化が必要になる理由です。 ## 実装上のTips - **`browser-use state` でJSレンダリング完了を確認してから `get text` する** — タイミング次第で空になる - **短時間の連続リクエストはブロックされやすい** — リクエスト間に数秒のウェイトを設ける - **アンチボット検出が強いサービスは `--profile` で実際のChromeプロファイルを使用する** - **`--session` オプションで名前付きセッションを使う**とマルチタスクがしやすい | エラー | 原因 | 対処 | | --- | --- | --- | | `get text` が空になる | JSレンダリング完了前にコマンドを実行 | `state` で確認後に実行 | | アクセスがブロックされる | アンチボット検出 | `--profile` で実際のChromeプロファイルを使用 | ## 懸念点 - **ブラウザ以外のデスクトップアプリは操作不可** — 汎用性はComputer Useのほうが高い - Python 3.11+ の環境構築が必要 - **2025年にlitellm経由のサプライチェーン攻撃が発生した経緯がある**（現在は依存から除去済みだが、任意LLM連携でlitellmを使う場合は慎重に） - OSSのため乗り換えコストは低いが、**提供元がクラウド版を強化した場合、セルフホスト版のサポートが薄れる可能性** ## よくある質問 ### Computer Useと何が違いますか？ **DOM解析か画面キャプチャかの違いです。**Browser Useはブラウザに特化してDOMを解析するため、WebVoyagerベンチマークで89%（Computer Use 56%）という精度差が出ています。ただしブラウザ以外のアプリは操作できません。 ### スクレイピングライブラリでは代替できませんか？ **JSレンダリングが必要なページでは代替できません。**クライアントサイドでデータが描画されるページは、`requests` や `curl` ではデータが入る前のHTMLしか取れません。 ### 費用はかかりますか？ **セルフホストなら$0です。**クラウド版は$0.05/stepの従量課金になります。Computer Useのトークン従量課金と比べるとコスト面で優位です。 ### 取得結果が空になります **JSレンダリングの完了前にコマンドを実行している可能性があります。**`browser-use state` でレンダリング完了を確認してから `get text` を実行してください。 ## まとめ - Web操作に限れば、**DOM解析ベースのほうが画面キャプチャベースより精度が高い**（WebVoyager 89% vs 56%） - **Daemonアーキテクチャによりコマンドレイテンシは約50ms**。連続操作を前提にした設計 - **既存のChromeプロファイルをそのまま使える**ため、ログイン済みサービスやアンチボット対策のあるページに強い - **MCP登録でClaude Codeから自然言語1文で実行できる** - JSでデータを描画するページは**スクレイピングライブラリでは取得できない**。ブラウザ自動化が必要になる - ブラウザ以外のアプリは操作不可。**汎用性と精度はトレードオフ** 自動化ツールの選定では、対象範囲を絞れるかどうかが精度を左右します。何でもできるツールより、目的に特化したツールのほうが結果的に確実です。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のリサーチ業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Claude Design Toolでどこまでできるか｜V0の代替として十分、ただし本番投入には手が要る - URL: https://ai-katsu.jp/articles/claude-design-tool - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-18T00:00:00+00:00 - Models: Claude - Tools: Figma - Tasks: 資料作成・デザイン, ツール検証 > リリース当日にClaude Design Toolを検証しました。短いプロンプトからヒーローレイアウト5種×カラースキーム5種の25通りを一度に生成。自然言語で慣性スクロールやパララックスを詰めていける対話体験と、コードがベタ書きで出力されるという実用上の課題をまとめています。 「こういう感じのサイトにしたい」という漠然としたイメージを、動くプロトタイプにするまでには通常いくつもの工程があります。 この検証では、リリース当日にClaude Design Toolを触り、**サイトリデザインの素案づくりから慣性スクロール・パララックスの調整まで**を実際に回しました。結論を先に書くと、**V0の代替としては十分。ただし出力コードはそのまま本番投入できません。** ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年4月16日（リリース当日に検証） | | 対象 | Claude Design Tool（Anthropic リリース、2026/04/16） | | 検証内容 | AIによるUIデザイン・プロトタイプ生成の実用性／既存デザインツールの代替可能性 | | 出力形式 | HTML / JSX（コンポーネント分割あり） | | 生成量 | **ヒーローレイアウト5種 × カラースキーム5種＝25通りを一度に生成** | | 状況 | 完了 | ## 結論：60点のプロトタイプを最速で出せる 評価を一言でまとめるとこうなります。 **60点クオリティのプロトタイプをかなりのスピードで生成できます。** この「60点」という表現は否定ではありません。**素案の段階で必要なのは100点ではなく、判断できる形になっていることです。**ここが速く出るなら、その後の議論が前に進みます。 | ツール | 位置づけ | | --- | --- | | V0 | **ほぼ不要になる。**ClaudeのUIプロト生成で代替可能 | | Figma | **ハイクオリティ仕上げ・デザインシステム管理には引き続き必要** | | Claude Design | **プロトタイプ・素案・PoC用途で最速** | ## 最初のターン：25通りを一度に出してきた 投げたプロンプトは次のような短いものです。 ``` こちらのサイトのデザインを刷新したいです、アイデア出してサンプル作りたいです。 Hi-fi design Interactive prototype ``` これに対しClaudeが方向性を決めるための質問を投げ、こちらが一括で回答しました。トーン（洗練・ミニマル）、カラー方向性（全く新しい配色）、ターゲット（企業）、ヒーロースタイル（アニメーションのあるヒーロー）、レイアウト（シングルページ）、バリエーション数（5パターン以上）といった項目です。 生成されたのは以下です。 **ヒーローレイアウト5種**（Tweaksパネルで切り替え可能） - A: 左寄せテキスト + 浮遊ジオメトリックシェイプ - B: 中央配置 + タイピングアニメーション - C: 左右分割 + モザイクグリッド - D: 超大型タイポグラフィ + アクセントライン - E: ミニマル縦ライン + スタッツカード **カラースキーム5種**：Slate × Sienna（琥珀系）／Mono × Indigo／Navy × Terracotta／Graphite × Blue／Warm × Olive 気づいた点は3つあります。 - **「Hi-fi design / Interactive prototype」というキーワードだけで、質の高いプロトタイプを前提に動いてくれた** - **質問→一括回答という形式でも、全項目を正確に解釈して実行プランを自律的に組み立てた** - **5レイアウト×5カラーの25通りを一度に生成する実行力はV0と比べて段違い** ## 自律的なデバッグ：3回リライトしてフォールバックを選んだ この検証で最も興味深かった挙動です。**こちらが何も指示していないターンで、Claudeが自律的にアニメーション実装の問題を検知し、複数回リライトを行いました。** 1. **第1試行**: JSステートベースのエントランスエフェクト実装 → Babel環境でJSステートが動作しないことが判明 2. **第2試行**: CSSクラスベース（`loaded` クラストグル方式）への書き換え → 同様に動作せず 3. **第3試行**: pure CSS `animation-delay` 方式に完全書き換え → スクリーンショット検証で動作確認できず 4. **最終解**: ヒーローコンテンツをデフォルト表示（`opacity: 1`）にし、CSSアニメーションはプログレッシブエンハンスメントとして残す ここから2つのことが分かります。 ひとつは、**検証環境の制約を認識したうえで、動く形に着地させる判断ができている**こと。「アニメーションは通常ブラウザでは動くが、検証環境のスクリーンショットでは動かない」という状況で、**コンテンツが確実に表示されることを優先しました。**フォールバック設計としては適切です。 もうひとつは構成の推測です。**スクリーンショット検証を担う内部エージェントの存在が確認でき、Claude Design Toolが単体のLLMではなくエージェント構成になっていることが示唆されました。** ## 対話で詰めていく体験 この検証の後半は、慣性スクロールとパララックスの調整に費やしています。実際のやり取りは次のようなものでした。 ### 「簡単で良いので」から適切な実装を選ぶ 「慣性スクロールとりいれれますか？ 簡単で良いのでFVあたりにパララックスの要素を入れてみたいです」という抽象的な指示に対し、**lerpベースの慣性スクロールドライバーを `useParallax()` フックとして切り出し、パララックス速度を3段階（slow / mid / fast）で実装**してきました。 **lerpという実装手法を明示していないのに選択してきた点**は、実装レベルの判断ができていることを示します。 ### 問題報告に対して根本から変えてくる 「パララックスの表示がカード形式の要素と重なっててわかりにくい」という報告に対する対応が印象的でした。 **位置を動かすだけでなく、デコレーション形状をカード風のボックスから `radial-gradient` の大型ソフトグロー（300〜450px）に変更し、画面端に配置して重なりを解消**しています。 **「重なる」という問題に対して、形そのものを変えるという解き方を自律的に選んでいます。** ### 矛盾して見える要件を正しく分解する 「もっとヘビーにしてスクロールしても今より動きの量を抑えたい」——一見すると矛盾する指示です。 これに対し、**lerp係数を0.025まで下げて停止後の余韻を強調（重い追従感）しつつ、パララックス移動量は約4割減**という対応をしました。 **慣性の重さとパララックス移動量は独立したパラメータである**と正しく解釈しています。 ### 短い指示でも文脈を保つ 「円形グロー　開始位置をもう少し下にして」という1行の指示に対し、**各ヒーローの円形グローの `top` 値を15〜20%付近に調整**。前のターンで左側に配置した円形グローのことだと文脈を維持できています。 また「パララックス移動量　もっと増やして」では、**抑えた値から約2倍に拡大（slow: -0.55 / mid: -0.35 / fast: 0.45）**。**数値の履歴を保持してスケール感を維持**していました。 ## 課題：コードがベタ書きで出力される 実用面での最大の課題です。 **単一HTMLやJSXのベタ書きコードが出力されます。コンポーネント分割・モジュール化の設計がなく、そのままサーバーにデプロイするには手が必要です。** 本番投入前に構造整理・リファクタリングが必要になります。**「動くものが出てくる」ことと「そのまま使える」ことは別**という整理です。 もうひとつの課題は仕上がりです。**高品質なデザインシステム・ブランドガイドラインとの整合には人手が必要で、デザイナーが「最初に出てきたものを調整する」フェーズは残ります。** ## デザイナーとノンデザイナー、それぞれへの示唆 ### デザイナーの仕事はどう変わるか - Figma/Adobe XDでポチポチ作る作業フェーズは**縮小していく** - **「AIにどう指示してデザインを仕上げるか」のプロンプト設計・仕組み整備が主業務になる** - **AIの出力を評価・修正できる「デザインの目」は引き続き必要** ### ノンデザイナー・PMは何を知っておくべきか - デザイン専門知識は不要になるが、**「良いデザインかどうかの判断軸」は必要** - エンジニアも含め、**デザイントレンドの概要把握**（ベントーデザイン、慣性スクロール、パララックス速度感など）が求められる - **専門用語を知らなくても「なんとなくのイメージを言語化できる」レベルで十分** この検証のやり取りがそれを示しています。「もっとヘビーに」「左側に配置して」といった自然言語でUIを詰められました。 ## よくある質問 ### V0の代わりになりますか？ **なります。**この検証では5レイアウト×5カラーの25通りを一度に生成しており、実行力の差は大きいと評価しています。 ### Figmaは不要になりますか？ **なりません。**ハイクオリティな仕上げとデザインシステムの管理には引き続き必要です。Claude Designはプロトタイプ・素案・PoC用途で最速という位置づけです。 ### 出力されたコードはそのまま使えますか？ **そのままでは使えません。**単一HTMLやJSXのベタ書きで出力され、コンポーネント分割・モジュール化の設計がありません。本番投入前に構造整理・リファクタリングが必要です。 ### デザインの専門知識は必要ですか？ **専門用語は不要ですが、良し悪しの判断軸は必要です。**「なんとなくのイメージを言語化できる」レベルで十分に調整できます。ただし出てきたものを評価できないと、仕上がりは上がりません。 ## まとめ - **60点クオリティのプロトタイプを高速で生成できる。**素案段階なら十分な水準 - 短いプロンプトから**5レイアウト×5カラーの25通りを一度に生成**。実行力はV0と比べて段違い - **指示していないターンでも自律的に問題を検知し、3回リライトしてフォールバック設計に着地**した - 「もっとヘビーに」「左側に配置して」といった**自然言語でUIを詰められる対話体験**。矛盾して見える要件も正しく分解する - 課題は**コードがベタ書きで出力される**こと。本番投入にはリファクタリングが必要 - デザイナーの仕事は**作業から「AIへの指示設計」と「出力の評価」へ移る** プロトタイプが速く出ると、議論の起点が「言葉」から「実物」に変わります。専門知識がなくても形にできるようになると、決められる人の範囲が広がります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の制作業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## MiniMax CLIで専用スクリプトを捨てる｜TTS・動画・画像・音楽をシェル一行に置き換える - URL: https://ai-katsu.jp/articles/minimax-mmx-cli - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-18T00:00:00+00:00 - Models: Claude Code - Tools: MiniMax - Tasks: 音声・翻訳・文字起こし, ツール検証 > MiniMax公式CLI「mmx-cli」のドキュメントを精査し、自作スクリプトをどこまで置き換えられるかを整理しました。TTS・動画・画像・音楽の生成は完全置き換え可能で、残るのはクローンボイスの新規登録のみ。エージェント連携用フラグとツール定義のエクスポート機能もまとめています。 AIのAPIをワークフローに組み込むとき、たいていは専用のスクリプトを書くことになります。しかし**そのスクリプト自体が保守対象**になります。 MiniMaxが公式CLI「mmx-cli」をリリースしたため、**スクリプトを排除してシェル一行に置き換えられるか**をドキュメント全体を読んで確認しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年4月18日 | | 対象 | MiniMax CLI（mmx-cli）／2026年4月リリースのOSS公式CLIツール | | インストール | `npm install -g mmx-cli` | | やりたかったこと | n8n・Claude Code・DifyなどのワークフローでMiniMax APIを直接叩く専用スクリプトを排除する | | 結論 | **TTS・動画・画像・音楽は完全置き換え可能。クローンボイスの「登録」だけスクリプトが残る** | | 状況 | 完了（ドキュメント精査ベース） | ## 結論：残るのは「クローンボイスの登録」だけ 置き換え可否を整理するとこうなります。 | やりたいこと | 置き換え可否 | | --- | --- | | TTS（プリセットボイス） | **完全置き換え可能** | | 動画生成 → ダウンロード | **完全置き換え可能** | | 画像生成 | **完全置き換え可能** | | 音楽生成（歌詞・スタイル細かく指定） | **完全置き換え可能** | | TTS（クローンボイス使用） | 登録だけAPIが必要。使用はCLI可（要検証） | | **クローンボイス登録** | **スクリプト継続必要** | | voice\_design | MCP経由のみ | 重要な整理はここです。**「クローンボイスを新規登録するときだけスクリプトが必要。一度登録してしまえば、あとはCLIで運用できる」** 登録は頻繁に行う作業ではありません。**日常的に回る部分がCLIで完結するなら、スクリプトの保守負担は実質的にほぼ消えます。** ## エージェント連携が設計に組み込まれている このCLIの最大のポイントです。**Claude Code・Cursor・OpenCodeなどのAIエージェント向けに設計されています。** | フラグ | 用途 | | --- | --- | | `--non-interactive` | 対話プロンプトを出さずにエラーで即終了 | | `--quiet` | スピナーなし、stdoutが純粋なデータのみ | | `--output json` | 機械可読なJSON出力 | | `--dry-run` | APIを実際に叩かずにリクエスト内容を確認 | | `mmx config export-schema` | 全コマンドをAnthropicやOpenAI互換のツール定義JSONとしてエクスポート | `--quiet` で**stdoutが純粋なデータになる**ため、安全にパイプできます。 ``` # stdoutが純粋データなので安全にパイプできる URL=$(mmx image generate --prompt "A sunset" --quiet) mmx vision describe --image "$URL" --quiet # 非同期動画生成のワークフロー TASK=$(mmx video generate --prompt "A robot" --async --quiet | jq -r '.taskId') mmx video task get --task-id "$TASK" --output json mmx video download --task-id "$TASK" --out robot.mp4 ``` 特に `mmx config export-schema` は効きます。**全コマンドをツール定義JSONとして出力できるため、エージェントに渡す定義を手書きする必要がありません。** **CLIツールをAIから呼ばせる設計を、提供側があらかじめ用意している**——という点が、単なるコマンドラインツールとの違いです。 ## 機能別にできること・できないこと ### TTS・音声合成（`mmx speech`） 想定より全部入りでした。 - 30種類以上のプリセットボイス（`mmx speech voices` で一覧確認） - speed・volume・pitchの調整 - **ストリーミング再生**（`--stream | mpv -` でリアルタイム再生） - ファイルから読み込み（`--text-file -` でstdinも可） - **字幕タイミングデータの取得**（`--subtitles`） - 音響エフェクト追加（`--sound-effect`）、カスタム発音指定（`--pronunciation from/to`） - モデル切り替え：`speech-2.8-hd`（デフォルト）、`speech-2.6`、`speech-02` - 40言語対応（`--language` でブースト） **字幕タイミングデータが取れる点**は、動画制作のパイプラインを組むうえで重要です。音声とテロップを別々に作る必要がなくなります。 ### 動画生成（`mmx video`） - テキストプロンプトから動画生成（デフォルト：`MiniMax-Hailuo-2.3`） - 高速版モデル切り替え（`--model MiniMax-Hailuo-2.3-Fast`） - **非同期実行 → task IDで進捗ポーリング**（`--async` + `mmx video task get`） - ダウンロードまで自動待機（`--download sunset.mp4`） - 最初のフレーム画像を指定（`--first-frame`）、完了時のWebhook通知（`--callback-url`） 不明点も残っています。**解像度・秒数の指定（768P/1080P、6s/10sの選択）がCLIフラグ上で明示されていません。** ### 画像生成（`mmx image`） - アスペクト比指定（`--aspect-ratio 16:9` など）、バッチ生成（`--n 3`） - **キャラクター一貫性**（`--subject-ref type=character,image=path`） - できないこと：**モデル切り替え（`image-01` のみ）／インペインティング・画像編集（生成のみ）** ### 音楽生成（`mmx music`） フラグが最も多く、かなり細かく制御できます。 - 歌詞付き生成（`--lyrics` / `--lyrics-file`）、インストゥルメンタル（`--instrumental`） - ボーカルスタイル指定（`--vocals "male and female duet, harmonies in chorus"`） - ジャンル・ムード・楽器・テンポ・BPM・キーをそれぞれ個別フラグで指定 - **曲の構成指定**（`--structure "verse-chorus-verse-bridge-chorus"`） - 参照アーティスト指定（`--references`）、避けたい要素の指定（`--avoid`） - **AIGCウォーターマーク埋め込み**（`--aigc-watermark`） ### テキスト生成・画像理解 テキスト生成（`mmx text`）はマルチターン会話、ストリーミング、システムプロンプト、JSON出力、ツール定義の渡し込みに対応。ただし**Function Callingの実行自体はCLI側では行いません（定義を渡すだけ）**。 画像理解（`mmx vision`）はローカルファイル・URL・file\_idを指定でき、自由なプロンプトで質問できます。**複数画像の同時入力と動画理解は非対応**です。 ## ボイスクローンの扱い ここだけ注意が必要です。 **クローンボイスの登録はCLI非対応**で、APIを直接叩く必要があります。 1. 音声ファイルをFile Upload APIでアップロード → `file_id` 取得 2. Voice Clone APIに `file_id` と任意の `voice_id` を渡してクローン作成 3. 生成された `voice_id` をTTS APIに渡して合成 登録済みクローンボイスの**利用**は `--voice voice_clone_xxxxx` の形でCLIから実行できる可能性が高いものの、こちらは未検証です。 また、**プロンプトからボイスを生成する `voice_design` はMCPサーバー経由でのみ利用可能**で、CLIには未実装です。 ## 料金（Pay as You Go） | 種別 | 単価 | | --- | --- | | テキスト（M2.7 input / output） | $0.3 / $1.2 per Mトークン | | 動画（Hailuo-2.3-Fast 768P 6s） | $0.19 / 本 | | 動画（Hailuo-2.3 768P 6s） | $0.28 / 本 | | 動画（Hailuo-2.3 1080P 6s） | $0.49 / 本 | | TTS turbo / HD | $60 / $100 per M文字 | | 音楽生成（Music-2.6） | $0.15 / 曲（〜5分） | | 画像生成（image-01） | $0.0035 / 枚 | | ボイスクローン（Rapid） | $1.5 / ボイス | ボリュームを一定以上使うなら、Token Plan（月額$10〜）のほうがコスパが良い場面もあります。 ## よくある質問 ### 専用スクリプトは不要になりますか？ **TTS・動画生成・画像生成・音楽生成は完全に置き換え可能です。**残るのはクローンボイスの新規登録だけで、これは頻繁に行う作業ではありません。 ### AIエージェントから呼び出せますか？ **そのために設計されています。**`--non-interactive`、`--quiet`、`--output json`、`--dry-run` が用意されており、`mmx config export-schema` で全コマンドをツール定義JSONとしてエクスポートできます。 ### クローンボイスは使えますか？ **登録はAPI経由が必要ですが、登録済みボイスの利用はCLIから可能と考えられます**（この検証時点では未検証）。プロンプトからボイスを生成する `voice_design` はMCP経由のみです。 ### 動画の解像度は指定できますか？ **CLIフラグ上では明示されておらず、要確認事項として残っています。**モデル選択（Hailuo-2.3 / Hailuo-2.3-Fast）による切り替えは可能です。 ## まとめ - TTS・動画・画像・音楽の生成は**CLIで完全置き換え可能**。専用スクリプトの保守負担が消える - 残るのは**クローンボイスの新規登録のみ**。一度登録すればあとはCLIで運用できる - **エージェント連携が設計に組み込まれている。**`--quiet` でstdoutが純粋データになり安全にパイプできる - **`mmx config export-schema` で全コマンドをツール定義JSONとして出力可能** - TTSは**字幕タイミングデータの取得**まで対応。動画制作パイプラインとの相性が良い - 動画の解像度・秒数指定はCLIフラグ上で不明。`voice_design` はMCP経由のみ APIを使った仕組みは、スクリプトが増えるほど保守が重くなります。公式CLIで置き換えられる部分を先に見極めておくと、構成を軽く保てます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のコンテンツ制作へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## ブラウザ版ClaudeからGitHubに書き込む｜OAuthの制約を自作MCPサーバーで回避する - URL: https://ai-katsu.jp/articles/github-remote-mcp-verification - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-15T00:00:00+00:00 - Models: Claude - Tools: GitHub, MCP, Cloudflare - Tasks: 開発・エンジニアリング, ツール検証 > claude.aiのOAuth連携は読み取りのみで書き込みができません。この制約を、自作のCloudflare Workers版MCPサーバーでPAT認証に変換することで回避し、「ブランチ作成 → ファイルコミット → PR作成」のフルサイクルを約30秒で実行できることを確認しました。Fine-grained PATの必要権限とUser-Agentヘッダー必須の落とし穴もまとめています。 ブラウザ版・スマホ版のClaudeからGitHubを操作したい——読み取りだけなら公式のGitHub MCPをOAuthで接続すればすぐに使えます。しかし**書き込みは通りません。** この検証では、その制約の正体を特定し、**自作のCloudflare Workers版MCPサーバー＋Fine-grained PAT**という構成で回避しました。結果として**「ブランチ作成 → ファイルコミット → PR作成」のフルサイクルをclaude.aiから一気通貫で実行できることを確認**しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年4月15日（1日で完結） | | 対象 | GitHub Remote MCP Server（公式 + 自作Cloudflare Workers版） | | バージョン | github/github-mcp-server（GA: 2025年9月4日）／自作版 初版 2026/04/15 | | やりたかったこと | claude.ai（ブラウザ・スマホ）からGitHubのIssue作成・ブランチpush・PR作成を行う | | 結果 | **書き込みフルサイクル成功。**ブランチ作成〜PR作成の一連が**約30秒** | | 運用コスト | Cloudflare Workers 無料枠内（10万req/日）：$0／GitHub Free：$0 | | 判定 | **条件付きで導入可**（自作Worker + Fine-grained PAT構成） | ## 結論：OAuthで書き込めないのは仕様ではなくアプリ側の設計 この検証で最も価値のある発見は、制約の正確な把握です。 **claude.aiのOAuth連携は書き込みスコープを持っていません。これはclaude.ai側の実装制約です。** ここは誤解されやすい部分です。「書き込み権限を与えると他ツールに伝播するリスクがある」という説明はOAuthの仕様上正確ではありません。正確には**「claude.aiのアプリが書き込みスコープを要求しない設計になっている」**という話です。 さらに、**claude.aiのカスタムコネクタUIはOAuth前提で、PATをAuthorizationヘッダーで渡す欄がありません。**つまりUI上で直接PAT接続に切り替えることもできません。 **制約の場所が分かれば、回避方法も決まります。**今回は「Worker側でPATに変換する」という構成をとりました。 ## 構成：OAuthとPATを橋渡しする ``` [GitHub API] ← PAT認証 ← [Cloudflare Worker（自作MCPサーバー）] ↑ OAuth（Client ID/Secret） [claude.ai カスタムコネクタ] ``` - claude.aiはWorkerに**OAuth**で接続する（Client ID / Secretで認証） - WorkerはGitHub APIを**PAT**で呼び出す **「OAuthで書き込めない」問題を、Worker側でPATに変換することで回避する構成**です。claude.aiから見ればOAuth接続、GitHubから見ればPAT認証になります。 ## Fine-grained PATに必要な権限 ここでも一度つまずいています。**初回のPATはFine-grained権限が不十分で `create_branch` が403エラー**になりました。 | Permission | 設定 | | --- | --- | | **Contents** | **Read and write** | | **Issues** | **Read and write** | | **Pull requests** | **Read and write** | | Metadata | Read（自動付与） | **`Read only` のままだと `create_branch` や `create_pull_request` が403になります。** Repository accessは**対象リポジトリのみ**に絞ります（All repositoriesは避ける）。**Fine-grained PATはリポジトリ単位・権限単位で絞れるため、アカウント全体に紐づくOAuthよりセキュリティを高くできます。** ## GitHub APIは User-Agent がないと403を返す 実装で最初に踏んだ落とし穴です。 **GitHub APIはリクエストに `User-Agent` ヘッダーが必須で、未設定の場合は403エラーになります。** ``` headers: { 'Authorization': `token ${env.GITHUB_PAT}`, 'User-Agent': 'github-remote-mcp-worker/1.0', // ← これが必須 'Content-Type': 'application/json', } ``` 403という同じステータスコードが、**権限不足とヘッダー不足という異なる原因で返ってきます。**切り分けの順番を知らないと時間を取られます。 ## 動作確認：フルサイクルの実績 ツール単位の検証結果は次のとおりです。 | ツール名 | 概要 | 結果 | | --- | --- | --- | | `debug_echo` | 引数をそのまま返すデバッグ用 | 正常動作（timestampカスタム確認） | | `list_issues` | Issue一覧取得 | 正常動作（#1〜#76 取得確認） | | `create_issue` | Issue作成 | 正常動作（Issue #77 作成確認） | | `get_file_contents` / `search_code` / `search_issues` | 読み取り系 | 正常動作 | | **`create_branch`** | フィーチャーブランチ作成 | **PAT更新後に動作確認済み** | | **`create_or_update_file`** | ファイルコミット | **PAT更新後に動作確認済み** | | **`create_pull_request`** | PR作成 | **PAT更新後に動作確認済み** | フルサイクルは **① create\_branch → ② create\_or\_update\_file → ③ create\_pull\_request** の順で実行し、PR作成まで完全に成功しています。 | 項目 | 測定結果 | | --- | --- | | 読み取り成功率 | 100%（OAuthで安定動作） | | 書き込み成功率（PAT権限付与後） | **100%** | | ブランチ作成〜PR作成（一連） | **約30秒**（3ツール連続実行の合計） | ## OAuthとPAT、どちらを使うか | 項目 | OAuth（公式Remote） | Fine-grained PAT（自作Worker） | | --- | --- | --- | | 設定の手軽さ | ◎ 数クリックで完了 | △ Worker + PAT設定が必要 | | 読み取り | ✅ | ✅ | | **書き込み** | **❌ claude.aiでは不可** | **✅ 全ツール動作確認済み** | | スマホ対応 | ✅ 読み取りのみ | ✅ 書き込みも可（Worker経由） | | セキュリティ | △ アカウント全体に紐づく | ◎ リポジトリ・権限単位で制御可 | | カスタマイズ性 | ✗ | ◎ ツール追加が自由 | **読み取りだけで十分ならOAuthが最も手軽です。**書き込みが必要な場合のみ、自作Worker + Fine-grained PATの構成を検討する形になります。 ## 導入コストの内訳 | 項目 | 工数 | | --- | --- | | OAuth接続（読み取り） | 約15分 | | Fine-grained PAT発行 | 約10分 | | Cloudflare Workersデプロイ（フォーク〜deploy + デバッグ込み） | **約2〜3時間** | | PATスコープ調整（権限不足エラー確認後の再発行） | 約15分 | PAT発行からclaude.ai接続完了までの目安は**約3〜4時間（初回）**です。 ## トラブルシューティング早見表 | 症状 | 原因 | 対処 | | --- | --- | --- | | `403 Resource not accessible by integration` | OAuthスコープ不足（claude.aiの制約） | 自作Worker + Fine-grained PATに切り替える | | `403 Resource not accessible by personal access token` | PATのFine-grained権限不足 | Contents / Pull requests を `Read and write` に変更して再発行 | | GitHub API `403`（初回疎通時） | `User-Agent` ヘッダー未設定 | fetchにUser-Agentを追加して `wrangler deploy` | | 新しいツールが認識されない | MCPツール一覧のキャッシュ | MCP接続をオフ→オン、または新しいチャットを開く | | `Session terminated (32600)` | tools/callレスポンス前にWorkerが終了 | Streamable HTTP statelessモードへの移行を検討 | ## 運用上の注意点 - **MCPサーバーのツール一覧はセッション開始時に読み込まれます。**新ツール追加後は新チャット、またはMCP再接続が必要です - **Cloudflare WorkersはPagesと異なりGitHubリポジトリと直接紐付けできません。**`wrangler deploy` の手動実行が基本になります - **PATはCloudflare Workersのシークレットで管理し、コードにハードコードしない** - **公開エンドポイントに認証なしでアクセスできる状態**のため、APIキー認証の追加が望ましい（この検証時点では未対応） - 公式リポジトリの最新を取り込むには `git remote add upstream` → `git fetch upstream && git merge upstream/main` ## よくある質問 ### claude.aiからGitHubに書き込めないのはなぜですか？ **claude.aiのOAuth連携が書き込みスコープを要求しない設計になっているためです。**OAuthの仕様上の制約ではなく、アプリ側の実装によるものです。 ### PATをUIから設定できませんか？ **できません。**claude.aiのカスタムコネクタUIはOAuth前提で、PATをAuthorizationヘッダーで渡す欄がありません。`Authorization: Bearer [JWT]` を直接入力できるUIも現状存在しません。 ### GitHub APIで403が出ます **権限不足と `User-Agent` ヘッダー未設定の2つの可能性があります。**まずリクエストにUser-Agentが含まれているか確認し、次にFine-grained PATのContents / Pull requestsが `Read and write` になっているか確認してください。 ### 費用はかかりますか？ **この構成では$0です。**Cloudflare Workersの無料枠（10万req/日）とGitHub Freeプランの範囲で運用できます。 ## まとめ - **claude.aiのOAuth連携は書き込みスコープを持たない。**これはclaude.ai側の実装制約 - 回避策は**自作Cloudflare Workers版MCPサーバーで、OAuth接続をPAT認証に変換する構成** - **「ブランチ作成 → ファイルコミット → PR作成」のフルサイクルをclaude.aiから約30秒で実行**できることを確認 - Fine-grained PATは**Contents / Issues / Pull requests を Read and write** に。`Read only` だと403 - **GitHub APIは `User-Agent` ヘッダー必須。**未設定でも403が返るため切り分けに注意 - 読み取りだけならOAuthで十分。書き込みが必要な場合のみWorker構成を検討（初回セットアップ約3〜4時間） AIエージェントに実際の作業をさせようとすると、必ず認証と権限の設計に突き当たります。どこで詰まるかを先に把握しておくと、構成の選択が速くなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAIエージェント導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 記事収集AIエージェントの設計｜2軸スコアリングと月額180円で回す構成 - URL: https://ai-katsu.jp/articles/note-article-analysis-agent - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-15T00:00:00+00:00 - Models: Claude - Tools: GitHub, Discord, Slack - Tasks: AIエージェント, 業務プロジェクト - Domain: マーケティング > バズ記事・有料記事を効率よく収集しDiscord・Slackへ配信するエージェントを設計しました。「1日あたりのengagement速度」と「フォロワー規模比」の2軸スコアにLLMのテーマ適合スコアを乗算する仕組み、処理時間から逆算したGitHub Actionsの選定理由、モデル使い分けによる月額約180円のコスト試算をまとめています。 情報収集を自動化するとき、最初に決めるべきは「どう集めるか」ではありません。**何を「良い記事」と判定するか**です。ここが曖昧なままだと、集まっても選べません。 この検証では、プラットフォーム上の記事を収集・分析してDiscordとSlackへ配信するエージェントを設計しました。**2軸のスコアリング式と、月額約180円という運用コスト試算**まで固めています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月15日〜（検証中） | | 使用予定ツール | note非公式API v3 / Python・httpx / Claude API（claude-sonnet-4-6）/ Discord Bot / Slack Webhook | | やりたかったこと | 技術・AI・ビジネスジャンルでバズっている記事・有料記事・SEO上位記事を効率よく収集・分析し、DiscordとSlackへ自動配信する | | 確定した設計 | **2軸のスコアリング式／GitHub Actionsによる定期実行／収集ハッシュタグ8種** | | コスト試算 | **約180円/月**（毎日1回実行） | | 状況 | 設計完了・実装前（API疎通は未実測） | > 本記事は自社での検証記録です。外部サービスのデータ取得は、各サービスの利用規約とrobots.txtの範囲内で行う必要があります。 ## 結論：「バズ」と「エンゲージメント率」の2軸で拾う この設計の中核はスコアリングです。1つの指標では、拾えるものが偏ります。 ``` # バズスコア: 1日あたりの engagement 速度 days = max((now - published_at).days + 0.5, 0.5) engagement_weight = likes + comments * 2 buzz_score = (engagement_weight / days) * (1.2 if is_paid else 1.0) # エンゲージメント率スコア: フォロワー規模比（無名クリエイターの良記事を拾う） eng_score = (engagement_weight / max(creator_followers, 100)) * (1.2 if is_paid else 1.0) # LLM テーマ判定でテーマ適合スコア 0.0〜1.0 を取得し乗算 final_buzz = buzz_score * theme_score final_eng = eng_score * theme_score # 各軸上位5件の Union（重複除去）→ 最大10件を配信 ``` 設計上のポイントは3つあります。 ### ① 絶対数ではなく「速度」で見る バズスコアは**1日あたりのengagement速度**です。公開からの日数で割ることで、**古くて数字が積み上がっただけの記事を上位に押し上げない**ようにしています。 ### ② フォロワー規模で割って、無名の良記事を拾う エンゲージメント率スコアは**フォロワー規模比**です。反応数だけで並べると、フォロワーの多いアカウントが常に上位を占めます。**規模で割ることで、フォロワーは少ないが刺さっている記事が浮かび上がります。** この2軸を**それぞれ上位5件取り、Unionで重複除去して最大10件を配信**する構成です。片方だけでは見落とす層があります。 ### ③ コメントを重く見る `engagement_weight = likes + comments * 2` という重み付けです。**コメントはスキより行動コストが高いため、内容への反応をより強く反映します。** ## LLMをスコアリングに組み込む 数値だけでは「テーマに合っているか」は判断できません。 そこで**LLMによるテーマ判定でテーマ適合スコア（0.0〜1.0）を取得し、両軸のスコアに乗算**しています。バズっていてもテーマが違えば、スコアは下がります。 **数値指標と意味判定を掛け合わせる構成**です。数値だけでも、AIの判断だけでも、選別としては不十分になります。 ## データ取得方法の調査結果 RSS / 公式API / 非公式API / スクレイピングを比較し、**非公式API v3をメインに採用**しました。 - **公式APIが存在しない**ため、非公式API v3（`https://note.com/api/v3/`）が広く使われている - 非公式API v3では**スキ数・有料フラグ・フォロワー数など豊富なデータが取得可能** - **RSSはユーザー別のみで、タグ別・人気記事別のフィードは存在しない**——収集用途には使えない - robots.txtでは `/n/*`（記事）`/m/*`（マガジン）のクロールは許可されている - **有料記事の本文は購入ユーザー権限が必要なため、タイトル・冒頭部分のみ取得可能** スクレイピングは**フォールバック扱い**です。利用規約で明示禁止はないものの、API優先で負荷を最小化する方針としました。レート制限対策として**1〜3秒のディレイ**を設定します。 ## 定期実行基盤：GitHub Actionsを選んだ理由 5つの選択肢を実行時間の観点で比較しました。 | 選択肢 | 実行時間上限 | 言語 | 無料cron頻度 | 評価 | | --- | --- | --- | --- | --- | | **GitHub Actions** | **6時間** | 何でも可 | 制限なし（Publicは完全無料） | **採用** | | Cloudflare Workers | 30秒（無料）/ 15分（有料） | JS/TSのみ | 可 | 実行時間・言語がネック | | Vercel | 10秒（無料）/ 60秒（Pro） | JS/TS主体 | 1日1回（無料） | 実行時間・コストがネック | | Google Apps Script | 6分/回 | JSのみ | 可（無料） | JSのみ・6分制限がネック | | Google Colab | セッション依存 | Python | 非対応（手動） | 自動化に不向き | 決め手は処理時間の見積もりです。**このエージェントは「レートリミットのディレイ込みのAPIフェッチ（20件）＋ Claude API呼び出し」で1〜2分かかる見込み**でした。 Cloudflare Workers（30秒）・Vercel（10秒）・GAS（6分）は実行時間がネックになります。**GitHub ActionsはPublicリポジトリなら完全無料・Pythonネイティブ・6時間制限で余裕**という判断です。 **定期実行基盤の選定は、まず「1回の処理に何秒かかるか」から入ると迷いません。**そこで大半の選択肢が落ちます。 ## コスト試算：月額約180円 | 項目 | 費用 | | --- | --- | | GitHub Actions（Publicリポジトリ） | $0 | | Claude Haiku（テーマ判定 × 20件） | 約45円/月 | | Claude Sonnet（通知文生成 × 10件） | 約135円/月 | | **合計** | **約180円/月** | 注目すべきは**モデルの使い分け**です。件数の多いテーマ判定（20件）には軽量なHaikuを、件数の少ない通知文生成（10件）にはSonnetを使っています。 **すべてを高性能モデルで処理する必要はありません。**判定のような単純な処理と、文章生成のような品質が求められる処理を分けると、コストは大きく下がります。 ## 収集対象 収集ハッシュタグは8種で確定しています。 `#生成AI` `#ChatGPT` `#LLM` `#Claude` `#AI活用` `#組織変革` `#経営` `#マーケティング` 配信先は**Discord（個人向け）とSlack（チーム向け）の2系統**です。同じ情報でも、読む相手によって必要な粒度が変わります。 ## 残っている未確認事項 この検証は設計段階のため、実測が必要な項目が残っています。 - API v3の疎通確認（まだ実測していない） - ビュー数フィールドの取得可否（実装時期によって不安定との報告あり） - レート制限の実測値（1〜3秒ディレイで十分かは未確認） - 有料記事の本文取得可否（購入権限が必要と推測） 非公式APIを使う以上、**仕様が変わる前提で設計しておく必要があります。** ## よくある質問 ### なぜスコアを2軸にするのですか？ **1軸だと拾える記事が偏るためです。**反応数の絶対値だけで並べるとフォロワーの多いアカウントが上位を占めます。フォロワー規模比の軸を足すことで、無名でも刺さっている記事を拾えます。 ### RSSでは足りないのですか？ **RSSはユーザー別のみで、タグ別・人気記事別のフィードが存在しません。**テーマ横断で収集する用途には使えないため、API経由での取得が必要になります。 ### なぜGitHub Actionsを選んだのですか？ **1回の処理に1〜2分かかる見込みだったためです。**Cloudflare Workers（30秒）・Vercel（10秒）・GAS（6分）は実行時間がネックになります。GitHub ActionsはPublicリポジトリなら完全無料でPythonネイティブ、6時間制限で余裕があります。 ### 運用コストはどのくらいですか？ **毎日1回の実行で約180円/月の試算です。**件数の多いテーマ判定に軽量モデル、件数の少ない通知文生成に高性能モデルを使い分けています。 ## まとめ - 情報収集の自動化で先に決めるべきは、集め方より**「何を良い記事と判定するか」** - スコアは**「1日あたりのengagement速度」と「フォロワー規模比」の2軸**。各軸上位5件のUnionで最大10件を配信 - **数値指標にLLMのテーマ適合スコア（0.0〜1.0）を乗算**し、数値と意味判定を掛け合わせる - 定期実行基盤は**処理時間の見積もりから選ぶ**。1〜2分かかる想定でGitHub Actionsを採用 - **モデルの使い分けでコストは約180円/月**。判定は軽量モデル、生成は高性能モデル - 非公式APIを使う以上、**仕様変更を前提に設計する** 収集の自動化は、フィルタの設計がすべてです。何を上位に出すかを数式で表現できれば、あとは実装の問題になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の情報収集・マーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 寝ている間もAIを動かす｜cron＋Claude Code CLIによる夜間自動実行の構築と権限の壁 - URL: https://ai-katsu.jp/articles/nightly-scheduled-tasks - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-15T00:00:00+00:00 - Models: Claude Code - Tools: Astro - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: 社内基盤・インフラ > 利用プランのレートリミットを日中だけでは使い切れないという課題から、cron（02:10）でClaude Code CLIを起動し記事を自動生成する仕組みを構築しました。生成自体は正常動作した一方、外付けSSDへのWrite権限がサブエージェントに引き継がれず保存に失敗。無人実行でつまずく3つのポイントを記録しています。 AIツールのサブスクリプションには、時間あたり・週あたりの利用上限があります。日中の作業だけでは使い切れず、**就寝中は活用率0%**です。 この検証は「寝てる間も動く仕組みを作りたい」という発想から始まりました。**cronで深夜2時10分にClaude Code CLIを起動し、記事を自動生成する仕組み**を構築しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月15日〜（検証中） | | 使用ツール | Claude Code CLI（`claude --permission-mode auto -p`）／macOS cron + `pmset`／Astro 6.1.4 + MDX | | 目的 | 非稼働時間帯（主に深夜〜早朝）にAIを自律的に動かし、週あたりのレートリミット消化率を最大化する | | 構築したもの | cron（02:10）→ `generate-ai-articles.sh` → `claude --permission-mode auto -p` → MDX保存 | | 成果 | **5記事分のドラフト内容の生成を確認（品質は既存記事と遜色なし）／保存成功は0件（権限問題により保留中）** | | 状況 | 進行中 | ## 結論：生成は動いた。詰まったのは権限だった この検証の現状を正確に書くと、こうなります。 **記事の内容生成自体は問題なく動作し、品質も既存記事と遜色ないレベルでした。しかし保存成功は0件です。**原因は生成ではなく、ファイル書き込みの権限にあります。 具体的には、**外付けSSDへのWrite権限がサブエージェントに引き継がれない**という問題です。 - `--permission-mode auto` でも、作業ディレクトリ外への書き込みは別途許可が必要 - `settings.local.json` の `allow` に `Write(/Volumes/...)` を追加したが、**サブエージェント（Agent toolで並列生成）には権限が完全には引き継がれなかった** - グローバル設定に追加しても解消せず 根本的な対処として、**対象プロジェクトをMac内蔵ストレージへ移行する方針に切り替え**ました。 **無人実行では、権限の設計がそのまま成否を分けます。**対話的に実行していれば都度許可すれば済む場面が、無人だとそこで止まります。 ## なぜcronを選んだのか スケジュール実行の手段はいくつかありますが、**既存のcronインフラに乗せる方針**を採用しました。 理由は**「Macが深夜に確実に起動している前提が成立しており、cronが最もシンプル」**だからです。 同様に、専用のTypeScriptスクリプト（SDK利用）ではなく**Claude Code CLIに `prompt.md` を渡す方式**を選んでいます。理由は**追加の依存関係がなく、WebSearchやAgent toolがCLI側で既に使えるため**です。 **すでに動いている仕組みの上に載せるほうが、新しく作るより確実です。**夜間実行は障害に気づきにくいため、部品を減らす判断が効きます。 ## バッチ実行の基本形 ``` claude --permission-mode auto -p "$(cat prompt.md)" ``` **この形がバッチ実行の基本形として機能します。**`-p` モードでプロンプトファイルを渡すだけで、WebSearchやAgentの並列実行が動きます。 トピック選定は `prompt.md` と `topic-queue.json` によるハイブリッド方式で設計しました。 ## ハマりポイント3つ ### ① `timeout` コマンドがmacOSに存在しない スクリプト内で `timeout 1740 claude ...` としていましたが、**macOSはデフォルトでGNU coreutilsを持たないため `timeout: command not found` で即終了**しました。 対処は `timeout` を除去してclaudeコマンドを直接実行することです。代替として `perl -e 'alarm(1740); exec @ARGV' -- command` を使うか、Homebrewで `coreutils` を入れて `gtimeout` を使う選択肢があります。 ### ② グローバル設定の `defaultMode: "plan"` がバッチ実行を妨害 **`~/.claude/settings.json` に `"defaultMode": "plan"` が設定されていたため、`--permission-mode auto` で起動してもプランモードに入り「承認いただければ実行を開始します」で停止**しました。 対処は、プロジェクト設定（`.claude/settings.local.json`）に `"permissions": { "defaultMode": "auto" }` を追加してオーバーライドすることです。 **無人実行では、確認を求めて止まる設定が致命的になります。**対話用の設定がそのまま効いていないか、確認が必要です。 ### ③ crontab書き込みがプロジェクト設定でブロックされた `.claude/settings.local.json` に `"allow": ["Bash(crontab -l)"]` のみ設定されており、`crontab /tmp/xxx` の書き込みがブロックされました。`"Bash(crontab /tmp/crontab_new.txt)"` をallowに追加して解決しています。 ## 安全側の設計：denyリストは auto でも有効 無人で動かす以上、暴走への備えが必要です。 **破壊的コマンド（rm / git push / sudo など）をdenyリストで永続ブロックしました。**重要なのは、**`deny` リストは `--permission-mode auto` でも有効**だという点です。 **「基本は自動で通す。ただし危険なものは常に止める」**という設計が、無人実行では現実的です。すべてを許可するのでも、すべてを確認するのでもない中間が必要になります。 ## 技術的な発見 - `claude --permission-mode auto -p "$(cat prompt.md)"` がバッチ実行の基本形 - `settings.local.json` の `permissions.defaultMode: "auto"` でグローバルの `plan` をプロジェクト単位でオーバーライドできる - `deny` リストは `--permission-mode auto` でも有効 - **外付けドライブへの書き込みは `additionalDirectories` だけでは不十分。`allow` への `Write(path/**)` の明示追加が必要だが、サブエージェントへの権限引き継ぎは不安定** ## 残っている課題 - 対象プロジェクトのローカル移行が完了していないため、記事の自動保存が未実現 - 移行後にスクリプト3箇所のパス更新が必要（`generate-ai-articles.sh` / `prompt.md` / `settings.local.json`） ## よくある質問 ### なぜ夜間に自動実行するのですか？ **利用プランのレートリミットを、日中の作業だけでは使い切れていないためです。**就寝中は活用率0%になるため、非稼働時間帯に自律的に動かして消化率を上げるという発想です。 ### なぜcronを使うのですか？ **Macが深夜に確実に起動している前提が成立しており、最もシンプルだからです。**すでに動いている仕組みに載せるほうが、新しく作るより確実に動きます。 ### 無人実行で気をつけることは？ **権限設定と、確認を求めて止まる設定です。**グローバル設定の `defaultMode: "plan"` が効いていると承認待ちで停止します。また、作業ディレクトリ外への書き込みは別途許可が必要で、サブエージェントへの権限引き継ぎは不安定です。 ### 暴走が心配ではないですか？ **破壊的コマンド（rm / git push / sudo など）をdenyリストで永続ブロックしています。**denyリストは `--permission-mode auto` でも有効です。 ## まとめ - **cron（02:10）→ シェルスクリプト → `claude --permission-mode auto -p` → MDX保存**という夜間実行の仕組みを構築 - **記事の内容生成は正常動作し品質も既存記事と遜色なし。ただし保存成功は0件**（権限問題により保留） - 詰まったのは**外付けSSDへのWrite権限がサブエージェントに引き継がれない**問題。ローカル移行で対処する方針 - **macOSに `timeout` は存在しない**。`gtimeout` か `perl -e 'alarm(...)'` で代替 - **グローバルの `defaultMode: "plan"` がバッチ実行を止める。**プロジェクト設定でオーバーライドする - **denyリストは auto モードでも有効。**「基本は自動、危険なものは常に止める」が無人実行の現実解 自動実行の仕組みは、動かす部分より止まる部分の設計に手間がかかります。無人で回すなら、権限と確認の挙動を先に洗い出しておくと詰まりにくくなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AI編集の履歴をGitで残す｜obsidian-gitでナレッジ管理を監査可能にする - URL: https://ai-katsu.jp/articles/obsidian-git - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-14T00:00:00+00:00 - Models: Claude Code - Tools: Obsidian, GitHub - Tasks: 開発・エンジニアリング, ツール検証 > ObsidianのvaultをGitリポジトリとして管理するobsidian-gitを検証しました。AIによるノート編集の監査ログとしてコミット履歴を活用する構成です。ObsidianがシェルPATHを引き継がない問題、外部ドライブ上のvaultが認識されない問題、モバイル同期の代替手段までをまとめています。 AIにノートを編集させるようになると、新しい課題が出てきます。**いつ、どこが、誰（何）によって書き換わったのかが分からなくなる**ことです。 この検証では、Obsidianのvaultをそのままリポジトリとして扱う**obsidian-git**を導入し、**Gitのコミット履歴をAI編集の監査ログとして使う**構成を作りました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月14日〜（検証中） | | 対象 | obsidian-git（Vinzent03/obsidian-git）v2.38.1（2026年4月12日リリース） | | やりたかったこと | Obsidianで編集 → 毎回ターミナルでgit操作、という手間をなくす／Claude Code編集 → 自動バックアップのフロー確立／AIによる編集の「監査ログ」としてGitコミット履歴を活用 | | 初期設定時間 | **約1時間**（トラブルシュート込み）／設定後の学習コストはほぼゼロ | | 費用 | **0円**（プラグイン無料、テキストノートならGitHub無料枠内） | | 判定 | **条件付きで導入可**（vaultを内部ストレージに置く前提） | ## 結論：AI編集の追跡にはGit履歴が最適 obsidian-gitを選んだ理由は、同期機能ではありません。 **Claude Codeと同一Gitリポジトリを共有するため、AI編集の追跡に最適だからです。** | 項目 | obsidian-git | Obsidian Sync（公式） | Remotely Save | | --- | --- | --- | --- | | 機能性 | Git操作フル対応 | 同期のみ | 同期のみ | | コスト | **無料** | 月額$8〜 | 無料〜 | | **変更履歴** | **Gitで完全保持** | なし | なし | | モバイル対応 | 不安定 | 安定 | 安定 | | Claude Code連携 | **最適（同一Gitリポジトリ）** | 不可 | 不可 | 同期だけが目的なら公式のObsidian Syncのほうが安定しています。**差がつくのは「変更履歴が残るか」です。**AIがノートを編集する運用では、この一点が重要になります。 ## ハマりポイント1：ObsidianはシェルのPATHを引き継がない 最初に詰まるのがここです。 **ObsidianはシェルのPATHを引き継がないため、gitバイナリのパスを明示的に設定する必要があります。** 設定場所は プラグイン設定 → **Advanced** → `Custom Git binary path`。ここに `/usr/local/bin/git` のような絶対パスを入力します。 **macOSでHomebrewやカスタムパスにgitをインストールしている場合は特に注意**が必要です。ターミナルでは動くのにObsidianからは見つからない、という状態になります。 ## ハマりポイント2：外部ドライブ上のvaultは認識されない gitバイナリのパスを設定してもエラーが消えませんでした。 **外部SSD（`/Volumes/` 以下）上のvaultで「Can't find a valid git repository」エラーが発生。**原因はmacOSのサンドボックスまたは外部ドライブのパス解決の問題と推測しています。 **解決策は、vaultを内部ストレージに移動することでした。**外部ドライブでの運用は避けるのが確実です。 | エラー | 原因 | 対処法 | | --- | --- | --- | | git not found / PATH error | ObsidianがシェルPATHを引き継がない | Custom Git binary pathに絶対パスを設定 | | Can't find a valid git repository | 外部ドライブ上のvault または Custom base pathの誤設定 | vaultを内部ストレージに移動、またはCustom base pathを空にする | ## .gitignoreの推奨設定 vault全体をそのままコミットすると、認証情報や作業状態まで含まれます。 ``` .obsidian/workspace.json .obsidian/workspace-mobile.json .obsidian/cache .obsidian/plugins/*/data.json .trash/ ``` 特に `plugins/*/data.json` は重要です。**プラグインによっては認証トークンがここに含まれる場合があります。**除外しておかないと、リポジトリに認証情報が入ります。 あわせて、**vaultルートに `CLAUDE.md` を配置してvault構造を説明する設計**にしています。AIが構造を把握したうえで編集できるようにするためです。 ## モバイルは「使わない」という判断 obsidian-gitのモバイル版については、明確に非推奨という結論です。 **iOSのObsidian Gitプラグインは、iOSサンドボックス制約によりネイティブgitバイナリを呼び出せないため事実上使用不可です。**モバイルではisomorphic-git（JS実装）が使われますが、公式に「非常に不安定」と明記されています。 無料運用を前提としたモバイル同期の選択肢を比較しました。 | 方法 | 費用 | 安定性 | 設定難易度 | 自動化 | | --- | --- | --- | --- | --- | | Obsidian Sync | 月額$8〜 | 安定 | 低 | 完全自動 | | **a-shell + lg2**（推奨） | **無料** | 中程度 | 中 | 半自動（Shortcuts可） | | Working Copy | $19.99買い切り | 安定 | 中 | 半自動（Shortcuts可） | | iSH + git | 無料 | 不安定 | 高 | 手動 | | Obsidian Gitプラグイン（iOS） | 無料 | 非常に不安定 | 低 | 不可（事実上使用不可） | a-shellでは**Unixの `git` コマンドではなく `lg2`（libgit2ベースの独自実装）を使います。**コマンド体系は同じですが呼び出し名が異なります。 日常のpull/pushは次のとおりです。 ``` # 起動時（PCの変更を取り込む） bookmark obsidian && cd knowledge-vault && lg2 pull origin # 終了時（変更をGitHubへ） bookmark obsidian && cd knowledge-vault && lg2 add . && lg2 commit -m "iOS update" && lg2 push origin ``` Apple Shortcutsに登録すれば1タップで実行できますが、**iOSのバックグラウンド制限により完全自動化はできません。** ## モバイルからの操作は別ルートで解決する この検証では、モバイル同期を無理に解決していません。用途で使い分ける方針をとりました。 - **スマホでノートを読みたい** → a-shell + lg2 でpullしてvaultを最新化 - **スマホからノートを書いてGitHubに反映したい** → a-shell + lg2 で add/commit/push - **スマホからClaude Codeでvaultを編集・操作したい** → Cloudflare Workers の Remote MCP経由（a-shellは不要） 3つ目が成立するのは、**ClaudeのiOSアプリがチャットUIであり、ローカルディレクトリを参照・マウントする機能を持たない**ためです。スマホからvaultをAIに操作させるなら、リモート経由が現実的という整理になります。 ## 制約：.mdxファイルは開けない もうひとつ確認できた制約です。 **`.md` ファイルは開けますが、`.mdx` ファイルは開けません。**AstroでContent Collectionsを利用するプロジェクトをObsidianと連携させることはできませんでした。 ドキュメントをObsidianで管理する前提を置くなら、**拡張子の選択が制約になる**という点は先に知っておく価値があります。 ## よくある質問 ### Obsidian Sync（公式）ではだめですか？ **同期だけが目的なら公式のほうが安定しています。**obsidian-gitを選ぶ理由は、変更履歴がGitで完全に残ることと、Claude Codeと同一リポジトリを共有できることです。 ### 「Can't find a valid git repository」が出ます **vaultが外部ドライブ上にある可能性があります。**この検証では外部SSD上のvaultで発生し、内部ストレージへ移動して解決しました。Custom base pathの誤設定でも同じエラーが出ます。 ### gitが見つからないと言われます **ObsidianはシェルのPATHを引き継がないためです。**プラグイン設定のAdvancedセクションにある `Custom Git binary path` に絶対パス（例: `/usr/local/bin/git`）を設定してください。 ### スマホでも使えますか？ **モバイル版obsidian-gitは非推奨です。**iOSサンドボックス制約でネイティブgitが呼べず、事実上使用できません。無料で運用するなら a-shell + `lg2` が現実的な代替になります。 ## まとめ - obsidian-gitの価値は同期ではなく**変更履歴が残ること**。AI編集の監査ログとしてGitコミット履歴を使える - **ObsidianはシェルPATHを引き継がない。**Advanced → `Custom Git binary path` に絶対パスを設定する - **外部ドライブ上のvaultはリポジトリとして認識されない。**内部ストレージに置くのが前提 - `.gitignore` で `plugins/*/data.json` を除外する（認証トークンが含まれる場合がある） - **モバイル版は事実上使用不可。**無料なら a-shell + `lg2`、AI操作はリモートMCP経由という使い分け - `.mdx` は開けないため、Content Collectionsを使うプロジェクトとは連携できない AIにドキュメントを触らせる運用では、「戻せること」と「差分が見えること」が安心材料になります。既存のGitの仕組みをそのまま使えるなら、追加のコストはほとんどかかりません。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のナレッジ管理とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## GitHubリポジトリの最低限のセキュリティ設定｜Dependabot有効化で11件の脆弱性が出た話 - URL: https://ai-katsu.jp/articles/github-repo-security-setup - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-07T00:00:00+00:00 - Models: Claude Code - Tools: GitHub - Tasks: 開発・エンジニアリング, ツール検証 > Claude Codeでgh apiを使ってリポジトリ設定を監査し、Rulesetsによるブランチ保護・Dependabot・CIのテスト実行を約30分で適用しました。Dependabot有効化直後に11件の脆弱性（high 5件・moderate 6件）を検出。Enforcementをactiveにしないとルールが効かない点など、実際に詰まったポイントも記録しています。 個人開発のリポジトリは、セキュリティ設定が後回しになりがちです。動いているうちは問題が見えないためです。 この検証では、Claude Codeで `gh api` を使ってリポジトリ設定を監査し、ブランチ保護・Dependabot・CIの設定を一通り適用しました。**Dependabotを有効にした直後、11件の脆弱性（high 5件・moderate 6件）が検出されました。** ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年4月7日（1日で完結） | | 対象 | GitHub Repository Settings（Rulesets / Dependabot / Branch Protection） | | やりたかったこと | 個人開発リポジトリにセキュリティ・運用設定のベストプラクティスを適用する | | 設定コスト | **約30分** | | 最大の発見 | **Dependabot有効化直後に11件の脆弱性（high 5件・moderate 6件）を検出** | | 状況 | 完了 | ## 結論：気づいていなかっただけで、脆弱性は存在していた この検証で最も直接的な成果はこれです。 **Dependabotを有効化した直後に11件の脆弱性（high 5件、moderate 6件）が検出されました。** 重要なのは、この11件が**この日に発生したわけではない**という点です。以前から存在していたものが、検知の仕組みを入れた瞬間に見えるようになっただけです。 **脆弱性の有無と、脆弱性に気づけるかどうかは別問題です。**設定コストは約30分ですが、放置している間はリスクが可視化されません。 ## 設定前の状態（監査結果） Claude Codeで `gh api` を使い、リポジトリの全設定を監査しました。 | カテゴリ | 項目 | 設定前 | リスク | | --- | --- | --- | --- | | ブランチ保護 | mainブランチルール | 未設定 | 高 | | ブランチ保護 | CIステータスチェック必須 | 未設定 | 高 | | 依存管理 | Dependabotセキュリティ更新 | 無効 | 高 | | 依存管理 | dependabot.yml | 未作成 | 中 | | CI/CD | テスト実行 | CIに含まれていない | 高 | | CI/CD | Node.jsバージョン | ワークフロー間で不一致 | 中 | | リポジトリ | マージ戦略 | 3種全て有効 | 低 | | リポジトリ | Auto delete branches | 無効 | 低 | | セキュリティ | Secret scanning / Push protection | 有効（OK） | — | ## ブランチ保護：Enforcement を Active にしないと効かない 最初につまずいた点です。 **Enforcement status を `Active` にしないとルールが一切効きません。**最初 `Disabled` で作成してしまい、設定したのに機能していませんでした。 設定したRulesetの構成は次のとおりです。 ``` Ruleset: main ├── Enforcement: active ← 最重要。これがdisabledだと全て無効 ├── Target: refs/heads/main ├── Rules: │ ├── deletion（ブランチ削除禁止） │ ├── non_fast_forward（force push禁止） │ ├── pull_request（PR必須、required approvals: 0） │ └── required_status_checks（CIのbuildジョブ必須） └── strict_required_status_checks_policy: true（マージ前にブランチ最新化必須） ``` また、**GitHub UIが「Branch protection rules（旧）」から「Rulesets（新）」に移行中**です。どちらでも同等の保護は可能ですが、**ネット記事は旧UIの情報が多いため注意が必要です。** ## 「マージ前にブランチ最新化必須」が防ぐ事故 `strict_required_status_checks_policy`（Require branches to be up to date before merging）が何を防ぐのかを整理しておきます。 ``` main: A ─── B ─── C (他のPRマージ) ← 今のmain \ feat: └── D (自分の変更) ← Cの変更を知らない → DだけでCIが通っても、C+Dの組み合わせで壊れる可能性がある → 「Update branch」でCを取り込み → CIが再実行 → 組み合わせでもOKを保証 ``` **これがないと「PRのCIは通ったけどマージ後に壊れる」事故が起きます。**複数人で開発する場合はもちろん、自分ひとりでも並行してPRを進めていれば発生します。 ## CIにテストを入れる 監査で見つかった問題のひとつが、**テストがCIで実行されていなかった**ことです。 ``` - run: npm ci - run: npm run test # ← 追加 - run: npm run check - run: npm run build ``` `npm run check`（astro check）と `npm run build` はありましたが、vitestが実行されていませんでした。 **テストを書いてもCIで実行しなければ意味がありません。**ブランチ保護でこのCIジョブを必須にしているため、テスト失敗＝マージ不可になります。 ## Dependabot：2つの設定が必要 Dependabotは、UIでの有効化と設定ファイルの両方が必要です。 ### A. GitHub UIでの有効化（Settings → Code security） - Dependabot alerts → Enable - Dependabot security updates → Enable これで脆弱性発見時に自動アラート＋修正PRが作られます。 ### B. 設定ファイル（`.github/dependabot.yml`） ``` version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" open-pull-requests-limit: 5 labels: - "dependencies" commit-message: prefix: "chore" - package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly" labels: - "dependencies" commit-message: prefix: "chore" ``` ここで押さえておきたい構造理解があります。 **`dependabot.yml` はGitHub Actionsのワークフローではありません。**`.github/` フォルダには2種類のものが入ります。 - `workflows/` → **GitHub Actionsランナーが実行** - `dependabot.yml`、PRテンプレート等 → **GitHubプラットフォーム本体が読み取って実行** 設定ファイルをリポジトリに置くだけで、GitHub側が自動で週次チェックを実行します。**npm依存だけでなく `github-actions` のバージョンも監視対象にすべき**です。 ## Node.jsバージョンをワークフロー間で統一する CIのワークフローはNode 22に更新済みでしたが、他のワークフローがNode 20のままでした。3ファイルともNode 22に統一しています。 **ワークフロー間でランタイムバージョンが異なると、CIは通るが別のActionで失敗するという事故が起きます。**Astro 6は `>=22.12.0` を要求するため、古い指定が残っていると動きません。 `.nvmrc` をリポジトリに置いてバージョンを一元管理する方法もあります。 ## マージ戦略はSquash mergeのみに絞る | 方法 | 設定 | 理由 | | --- | --- | --- | | Merge commit | **OFF** | 履歴が複雑になる | | **Squash merge** | **ON** | 1PR=1コミットで履歴がクリーン | | Rebase merge | **OFF** | コンフリクト時にややこしい | **Squash mergeにするとPRタイトルがそのままコミットメッセージになります。**Conventional Commits形式（`feat:`、`fix:` 等）でPRタイトルを付ければ、mainの履歴が自然と整います。 個人開発ではSquash merge一択が最もシンプルです。 ## 再利用できる監査コマンド 他のリポジトリでもそのまま使えます。 ``` # リポジトリ設定の確認 gh api repos/OWNER/REPO --jq '{ default_branch, allow_merge_commit, allow_squash_merge, allow_rebase_merge, delete_branch_on_merge }' # セキュリティ設定の確認 gh api repos/OWNER/REPO --jq '.security_and_analysis' # ブランチ保護ルールの確認 gh api repos/OWNER/REPO/branches/main/protection # Rulesets の確認 gh api repos/OWNER/REPO/rulesets gh api repos/OWNER/REPO/rulesets/RULESET_ID | jq '{name, enforcement, rules}' # Secrets の確認（値は見えない） gh api repos/OWNER/REPO/actions/secrets --jq '.total_count' ``` ## .gitignoreの補完 | カテゴリ | パターン | 理由 | | --- | --- | --- | | macOS | `.DS_Store` | Finderが全ディレクトリに生成 | | macOS | `._*` | 外部ドライブで特に発生しやすい | | macOS | `.AppleDouble`, `.Spotlight-V100`, `.Trashes` | 外部ドライブのメタデータ | | エディタ | `.vscode/`, `.idea/`, `*.swp` | 個人設定の混入防止 | | テスト | `coverage/` | vitest --coverage の出力 | | ログ | `*.log`, `npm-debug.log*` | デバッグログ | | ホスティング | `.vercel`, `.netlify` | 将来の移行に備え | ## よくある質問 ### 個人開発でもブランチ保護は必要ですか？ **必要です。**設定コストは約30分程度ですが、mainへの直push・CIスキップ・脆弱性の未検知といったリスクを防げます。 ### Rulesetを作ったのに効きません **Enforcement status が `Active` になっているか確認してください。**`Disabled` のままだとルールは一切効きません。 ### dependabot.yml を置くだけで動きますか？ **設定ファイルに加えて、GitHub UIでの有効化（Settings → Code security）も必要です。**なお `dependabot.yml` はGitHub Actionsのワークフローではなく、GitHubプラットフォーム本体が読み取って実行します。 ### 「マージ前にブランチ最新化必須」は何を防ぎますか？ **「PRのCIは通ったけどマージ後に壊れる」事故です。**自分の変更だけでCIが通っても、その間にマージされた他の変更との組み合わせで壊れる可能性があります。 ## まとめ - **Dependabot有効化の直後に11件の脆弱性（high 5件・moderate 6件）を検出。**気づいていなかっただけで存在していた - Rulesetは**Enforcement を Active にしないと一切効かない**。GitHub UIは旧「Branch protection rules」から「Rulesets」へ移行中 - **strict\_required\_status\_checks\_policy** で「CIは通ったがマージ後に壊れる」事故を防ぐ - **テストを書いてもCIで実行しなければ意味がない。**ブランチ保護でCI必須にすればテスト失敗＝マージ不可 - `.github/` には**Actionsが実行するもの（workflows/）とGitHub本体が読むもの（dependabot.yml等）の2種類**がある - マージ戦略は**Squash mergeのみ**に絞ると履歴が整う。設定コストは全体で約30分 セキュリティ設定は、問題が起きてから入れると被害の確認から始まります。検知の仕組みだけでも先に入れておくと、判断できる状態を保てます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制の整備を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 同一ドメインでWordPressとVercelを共存させる｜Cloudflare Workerによるパス振り分け設計 - URL: https://ai-katsu.jp/articles/cloudflare-dns-worker-proxy - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-07T00:00:00+00:00 - Tools: Cloudflare, Vercel - Tasks: 開発・エンジニアリング, ツール検証 > 「WordPressのドメインの/blogだけをVercelに向けたい」という要件を、Cloudflare Workerのルーティングで実現しました。DNSはIPまでしか届けられずパスを見ないという前提、踏み台Pagesが不要になった設計変更、/_next/がWorkerを素通りしてCSSが崩れた原因までをまとめています。 「WordPressで動いているサイトの `/blog` だけを別のホスティングに向けたい」——この要件は、DNSの設定だけでは実現できません。 理由は単純です。**DNSはIPアドレスまでしか届けられず、パスを見ないから**です。この検証では、Cloudflare Workerを使って同一ドメイン上にWordPressとVercelを共存させる構成を作りました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月7日〜（検証中） | | 使用ツール | Cloudflare Workers / Cloudflare DNS / Vercel（Next.js）/ WordPress（レンタルサーバー） | | やりたかったこと | WordPressで動いているドメインの `/blog` パスだけをVercelの静的サイトに向ける | | 成果 | `/blog/` でVercelのコンテンツが表示されることを確認。**手順書（Step1〜6、約200行のMarkdown）と全体構成図を整備** | | Workerコード | **約30行**（`isVercelPath` 関数 + fetch転送ロジック） | | コスト | Cloudflare Free：$0／Vercel Free：$0（Workersも個人用途はFreeで対応可） | ## 結論：DNSはIPまでしか届けられない この検証で最も重要な概念がこれです。 **`example.com/blog` と `example.com/` のどちらも、DNS解決の結果は同じIPです。パスによる振り分けはLayer7（アプリケーション層）での処理が必要になります。** DNSレコードにはAレコード、CNAME、MX、TXT、NS、CAAといった種類がありますが、**どれもパスを見る仕組みを持ちません。**「ドメイン名 → IPアドレス」の対応表だからです。 ここを理解していないと、よくある事故が起きます。**Aレコードを新しいホスティング先に向けた結果、WordPress全体が飛ぶ**というものです。パスだけ変えたつもりが、ドメイン全体の向き先を変えてしまっています。 **パス振り分けはWorkerの仕事。**この一言が構成の全体像を決めます。 ## サブパスとサブドメイン、どちらを選ぶか | 方式 | 例 | 実現方法 | | --- | --- | --- | | サブドメイン方式 | `app.example.com` | CNAMEで実現できる（簡単） | | **サブパス方式** | `example.com/blog` | **DNSでは不可。Workerによるルーティングが必要** | 今回サブパス方式を採用したのは、**要件が「同一ドメインでVercelを表示したい」だったため**です。CNAMEを使うサブドメイン方式では要件を満たせません。 技術的な難易度はサブドメイン方式のほうが低いため、**要件がURLの見た目にこだわらないなら、そちらを選ぶほうが早い**という判断もあり得ます。 ## 「踏み台Pages」は不要だった 設計変更の記録として残しておきたい点です。 当初はドメインの受け口としてCloudflare Pagesを挟む「踏み台Pages」構成を想定していました。しかし検証の過程で、**Cloudflare Workers の Settings → Domains & Routes → Custom Domain でカスタムドメインをWorkerに直接紐づけられる**ことが判明しました。 Pagesは不要になり、手順がシンプルになります。**これはCloudflareを使ったプロキシ戦略の中でも最もシンプルな構成**です。 あわせてCustom DomainとRouteの違いも整理しました。 - **Custom Domain** — ドメインまるごと紐づけ（シンプル） - **Route** — パターンマッチング（`example.com/blog*`）で細かく制御可能 ## CSSが崩れる原因：`/_next/` がWorkerを素通りしていた 実装で最も詰まったのがここです。 ページ自体は表示されるのに、**CSSが崩れる**という状態になりました。原因は、**Next.jsの静的アセットが `example.com/_next/static/...` から取得されるため、`/blog` の条件だけではWorkerを素通りして404になっていた**ことです。 対応は、**`isVercelPath` 関数に `/_next/` と `/favicon` の条件を追加して再デプロイ**することでした。 **サブパスでフレームワークをホストする場合、ページのパスだけを転送しても足りません。**そのフレームワークがどこからアセットを取りに行くかを確認する必要があります。 ## DNS移行時のMXレコードリスク この構成に入る前段として、Cloudflareへのネームサーバー移管があります。 **移管時、MXレコードが自動スキャンで取り込まれない場合があるため、移管前のスクリーンショット保管が重要です。**MXが欠けたまま切り替わると、メールが止まります。 あわせて、Cloudflareの「オレンジクラウド」のオン/オフはプロキシのオン/オフを意味します。**多くのエンジニアが混同しやすいポイント**ですが、「DNSはIPまでしか届けられない」という前提を置くと理解しやすくなります。 ## ドキュメントで詰まった点 技術以外の記録も残しています。 - **初版の手順書に「踏み台Pages」が含まれており、実際の構成と乖離していた** — 手順書の初版作成前に「踏み台Pagesは本当に必要か」を先に検証すべきだった - **構成図の日本語フォント問題** — DejaVu Sansでは日本語が欠落し、2回作り直しが発生。`plt.rcParams['font.family'] = 'IPAGothic'` を明示的に指定して解決 構成図の生成はPython（matplotlib）で行っています。**日本語を含む図を生成するなら、フォント指定をデフォルトの手順に組み込んでおくと作り直しが減ります。** ## 残っている課題 - Vercel側のNext.jsプロジェクトで `basePath: '/blog'` の設定が必要なケースがある（フレームワーク依存） - 他ドメインでの汎用性検証は未実施 ## よくある質問 ### なぜDNSだけでパスの振り分けができないのですか？ **DNSはドメイン名をIPアドレスに変換する仕組みで、パスを見ないためです。**`example.com/blog` も `example.com/` も、DNS解決の結果は同じIPになります。パス振り分けはLayer7での処理が必要です。 ### Cloudflare Pagesを踏み台にする必要はありますか？ **不要です。**Workers の Settings → Domains & Routes → Custom Domain でカスタムドメインをWorkerに直接紐づけられます。この方式が最もシンプルです。 ### CSSが崩れるのはなぜですか？ **Next.jsの静的アセットが `/_next/static/...` から取得されるためです。**Workerのルーティング条件に `/blog` だけでなく `/_next/` も含める必要があります。 ### ネームサーバー移管で注意することは？ **MXレコードが自動スキャンで取り込まれない場合があります。**移管前にDNSレコードのスクリーンショットを保管しておくことを推奨します。 ## まとめ - **DNSはIPまでしか届けられない。パス振り分けはWorkerの仕事**——これが構成の出発点 - サブパス方式（`example.com/blog`）はDNSでは実現できず、**Cloudflare Workerによるルーティングが必要** - **Custom DomainをWorkerに直接紐づけられるため「踏み台Pages」は不要**。最もシンプルな構成になる - CSSが崩れる原因は**`/_next/` パスがWorkerを素通りしていたこと**。アセットのパスも転送条件に含める - ネームサーバー移管時は**MXレコードが自動スキャンで漏れることがある**。移管前の記録が重要 - Workerコードは**約30行**、ホスティングコストは**$0**（Cloudflare Free + Vercel Free） 同一ドメインで複数のサービスを共存させる構成は、既存サイトを残したまま新しい仕組みを足したいときに有効です。どのレイヤーで振り分けるかを最初に決めておくと、事故を避けられます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のWeb・インフラ構築を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Astro×CMSの構成をどう選ぶか｜チーム・コスト・リアルタイム性の3軸 - URL: https://ai-katsu.jp/articles/astro-cms-architecture - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-06T00:00:00+00:00 - Tools: Astro, Webflow - Tasks: 開発・エンジニアリング, ツール検証 > Astroでのコンテンツ管理構成を5パターン整理しました。選定は技術的な優劣ではなく「誰が更新するか」で決まります。ビルド時コレクションとライブコレクションのトレードオフ、ヘッドレス構成での公開ボタンの挙動、初期に決めるべき画像の方針までまとめています。 Astroでサイトを作るとき、**「コンテンツ管理をどうするか」は避けて通れない設計判断**です。しかしこの判断は技術的な優劣では決まりません。 この記事では、**チーム構成・コスト・リアルタイム性の3軸**からアーキテクチャを選定する方法を整理します。 ## この記事の概要 | 項目 | 内容 | | --- | --- | | 作成日 | 2026年4月6日 | | 主題 | Content Collectionsの仕組みを理解したうえでの構成選定 | | 判断軸 | **チーム構成 / コスト / リアルタイム性** | | 整理したパターン | **5つ** | ## 結論：3つの問いで決まる ``` 編集者にエンジニア以外がいるか？ ├─ No → Astroのみ（MDファイル＋Git） └─ Yes ↓ 即時反映が必要か？ ├─ Yes → ライブコレクション＋SSR │ （インフラコスト増を許容） └─ No（数分のタイムラグを許容） ↓ コストを抑えたいか？ ├─ Yes → ヘッドレスCMS＋Webhook＋Astro静的ビルド ← 現実解 └─ UX重視 → 有料ヘッドレスCMS＋Astro ``` **多くのケースは2つのパターンに落ち着きます。**迷ったらシンプルな方を選び、必要になった時点でスケールアップするほうが失敗しにくくなります。 ## Content Collections の要点 Astroが提供する、コンテンツファイルを**型安全に管理・取得するための仕組み**です。 - Zodによるスキーマ定義で、フロントマターの型チェック・バリデーションが効く - `getCollection()` / `getEntry()` などの専用APIで取得する - **ローカルファイルだけでなく、外部CMS・APIからのデータも同じAPIで扱える** 最後の点が重要です。**ここが単なる「Markdownブログ機能」との違いで、外部データソースも統一的に扱えるためCMS連携の構成選定に直結します。** ## ビルド時コレクションとライブコレクション | | ビルド時コレクション | ライブコレクション | | --- | --- | --- | | データ取得タイミング | ビルド時 | リクエスト時 | | 設定ファイル | `src/content.config.ts` | `src/live.config.ts` | | 主なAPI | `getCollection()` / `getEntry()` | `getLiveCollection()` / `getLiveEntry()` | | **パフォーマンス** | **高い（静的HTML）** | リクエストごとに取得 | | 即時反映 | 不可（ビルドが必要） | **可能** | | **MDX・画像最適化** | **対応** | **非対応** | | 向いているケース | ブログ・ドキュメント・LP | 在庫・株価・リアルタイムデータ | **基本方針：ビルド時コレクションを優先し、リアルタイム性が必要な場合のみライブコレクションを使う。** 大半のWebサイトはビルド時で十分です。**ライブコレクションはパフォーマンスとインフラコストのトレードオフを伴う**ため、本当に必要なケースに限定します。 見落としやすいのが**MDXと画像最適化が非対応**という点です。リアルタイム性と引き換えに失うものがあります。 ## 5つの構成パターン ### パターンA：エンジニアのみのチーム ``` MDファイル（Git管理） → Astro → 静的HTML → VPS公開 ``` - CMSは不要、Astroだけで完結 - 記事はMarkdownで書いてGitにコミットするだけ - **コストが最も低い** - **非エンジニアには不向き** 個人ブログや技術ドキュメントサイトなら、まずこれを検討します。 ### パターンB：非エンジニアの編集者がいる（推奨） ``` CMS（管理画面専用・外部非公開） ↓ 公開ボタン → Webhook発火 CIでAstroビルド実行 ↓ CMSのREST APIから記事取得 デプロイ → 一般ユーザが閲覧 ``` - **編集者は管理画面だけ触ればよい** - ライセンスコストなし（サーバ代のみ） - **公開から反映まで数分のタイムラグあり**（運用ルールとして許容する） - **最もバランスが良い現実解** ### パターンC：GitベースのGUI ``` 編集者がブラウザ上の専用GUIで記事作成 ↓ 実態はGitへのコミット Push → 自動ビルドトリガー → デプロイ ``` 追加のCMSサーバが不要でコストが安い一方、**Gitホスティングのアカウント管理が必要**になります。 ### パターンD：有料ヘッドレスCMS - 専用の編集GUIが洗練されており使いやすい - **エントリ数・APIコール数で課金されるためコストが膨らみやすい** - 小〜中規模では過剰投資になりがち ### パターンE：ライブコレクション × SSR 即時反映が必要な場合の選択肢です。**サーバを常時稼働させる必要があり、インフラ管理コストが増えます。**在庫・価格など頻繁に変わるデータ向けです。 ## 推奨構成の役割分担 パターンBが現実解とされる理由を、役割分担で見ると明確になります。 | | CMS側（管理画面専用） | Astro側（公開サイト） | | --- | --- | --- | | **役割** | **記事データの置き場所** | **表示・デザインすべて** | | 担当 | 記事作成・編集／カテゴリ・タグ管理／画像アップロード | 静的ページ／記事ページ／統一されたデザイン・UX | **CMSは「裏方のデータ管理ツール」、Astroは「それを使って自由に表現するフロントエンド」**という分離です。 この分離により、**CMSのテーマやプラグインに縛られず、Astro側で完全にデザインをコントロールできます。**CMSはあくまで「編集者が使い慣れた管理画面」として活用します。 ## 誤解しやすい：公開ボタンの挙動 ヘッドレス構成でよくある誤解です。 - **公開ボタンを押すと、CMSとしての公開とWebhook発火が同時に起きる** - **「どちらか一方」を選ぶ操作は標準機能にはない** - CMSのフロントエンドURLを外部公開しないことで、実質的に「Astroサイトだけが見える」状態を作る 外部に見せない方法は2つあります。 - **Basic認証をかける** - **プライベートネットワークに閉じて、AstroからのAPIアクセスのみ許可する** なお**Webhookの発火にはプラグインが必要**で、「記事ステータスがpublishになったら指定URLへPOSTする」という設定を入れます。 ## 画像の扱いは初期に決める 後回しにしがちですが、**サイト規模が大きくなると確実にボトルネックになります。** | 規模 | 方針 | | --- | --- | | 小規模 | CMSの画像URLを直接参照しても問題ない | | 本格運用 | 外部ストレージに逃がすプラグインを使う | | **パフォーマンス重視** | **ビルド時に画像をダウンロードしてAstro側で最適化する** | ヘッドレス構成では、**記事内の画像がCMSサーバに置かれたままになります。**初期設計の段階で方針を決めておくのが望ましい部分です。 ## よくある質問 ### どの構成を選べばよいですか？ **3つの問いで決まります。**編集者にエンジニア以外がいるか、即時反映が必要か、コストを抑えたいか。多くのケースは「Astroのみ」か「ヘッドレスCMS + Webhook + 静的ビルド」に落ち着きます。 ### ライブコレクションを使うべきですか？ **リアルタイム性が本当に必要な場合に限定してください。**パフォーマンスとインフラコストのトレードオフに加え、MDXと画像最適化が使えなくなります。 ### ヘッドレス構成でCMSを外部に見せたくないのですが **Basic認証をかけるか、プライベートネットワークに閉じてAstroからのAPIアクセスのみ許可します。**公開ボタンはCMS公開とWebhook発火が同時に起きるため、URLを見せない設計で対応します。 ### 画像はどう扱いますか？ **規模によります。**小規模ならCMSのURLを直接参照、本格運用なら外部ストレージ、パフォーマンス重視ならビルド時にダウンロードして最適化します。初期に方針を決めておくべき部分です。 ## まとめ - 構成選定は**チーム体制・コスト・リアルタイム性の3軸**で決まる - Content Collectionsは**外部CMS・APIも同じAPIで扱える**点が本質 - **ビルド時コレクションを優先し、ライブは本当に必要な場合だけ**——MDXと画像最適化が使えなくなる - **現実解はヘッドレスCMS + Webhook + 静的ビルド。**数分のタイムラグを運用で許容する - 役割分担は**CMSがデータの置き場所、Astroが表示のすべて** - **公開ボタンは「CMS公開」と「Webhook発火」が同時に起きる。**URLを見せない設計で対応する - **画像の方針は初期設計で決める。**後から必ずボトルネックになる アーキテクチャの選定は、技術的な優劣より「誰が更新するか」で決まります。迷ったらシンプルな方から始めて、必要になってから足すほうが失敗しにくくなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のWeb構築とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Claude Computer UseをDockerで動かす｜Firefox自動操作環境の構築と精度を左右するプロンプト設計 - URL: https://ai-katsu.jp/articles/claude-computer-use - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-06T00:00:00+00:00 - Models: Claude - Tools: Computer Use - Tasks: リサーチ・データ収集, ツール検証 > Docker（Ubuntu 24.04 + Xvfb + XFCE4 + noVNC）上にComputer Use用のデスクトップ環境を構築し、Firefoxの自動操作を検証しました。タスクは15イテレーションで成功。Ubuntu 24.04のsnap移行によるFirefox起動問題、macOS前提コードのLinux移植、そして精度を決めるシステムプロンプト設計をまとめています。 AIにパソコンを操作させる「Computer Use」は、APIを叩けば動くものではありません。**操作対象となるデスクトップ環境そのものを用意する必要があります。** この検証では、Docker上にUbuntu＋XFCE＋Firefoxのデスクトップを構築し、noVNC経由で操作を可視化する環境を作りました。タスク「Firefoxでgoogle.comを開いてClaude AIを検索して」は**15イテレーション・30メッセージ交換で成功**しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年4月6日（1日で完結） | | 対象 | Claude Computer Use（Anthropic API beta機能） | | バージョン | API beta flag `computer-use-2025-01-24`／モデル `claude-sonnet-4-20250514` | | やりたかったこと | Computer Use APIの実用性を検証し、業務自動化PoCの基盤環境を構築する | | 結果 | **タスク成功（15イテレーション・30メッセージ交換）** | | 状況 | 完了 | ## 結論：システムプロンプトが精度を決める Computer Useを動かして最も強く感じたのはこれです。 **システムプロンプトが非常に重要です。環境に合わない指示（macOSコマンド等）があると、エージェントが迷走します。** 実際に効果があったのは、次のような明示的な制約でした。 - **「使えるブラウザはFirefoxのみ」** - **「macOSコマンドは使うな」** 制約を書く理由は、失敗時の挙動にあります。**エージェントは失敗するとChromiumのインストールやテキストブラウザに逃げがちです。**放っておくと、本来の目的から離れた作業を始めます。プロンプトで先回りして封じておく必要があります。 **Computer Useの精度は、モデルの能力だけでなく「環境の説明をどれだけ正確に与えたか」で変わります。** ## 技術構成 | コンポーネント | 技術 | | --- | --- | | コンテナ | Ubuntu 24.04（Docker） | | 仮想ディスプレイ | Xvfb | | デスクトップ | XFCE4 | | VNCサーバー | x11vnc | | Webアクセス | noVNC（websockify） | | ブラウザ | Firefox 149.0（Mozilla公式バイナリ） | | AI API | Anthropic Computer Use beta | | Python | pyautogui, Pillow, anthropic SDK | noVNCを挟むことで、**http://localhost:6080 でFirefoxの操作がリアルタイムに可視化されます。**AIが何をしているかを見られるのは、検証段階では重要です。 ## Ubuntu 24.04でFirefoxが起動しない 最も時間を要した問題です。 **Ubuntu 24.04の `firefox` パッケージはsnap版への移行パッケージであり、Dockerコンテナ内ではsnapdが動作しないため実体がありません。** 試した対応は2つです。 | 試したこと | 結果 | | --- | --- | | Mozilla Team PPA（`ppa:mozillateam/ppa`） | ARM64でダウンロードが極端に遅く断念 | | **Mozilla公式バイナリ直接ダウンロード** | **成功** | 採用したDockerfileの記述は次のとおりです。 ``` RUN ARCH=$(uname -m) && \ if [ "$ARCH" = "aarch64" ]; then ARCH="linux64-aarch64"; else ARCH="linux64"; fi && \ wget -q "https://download.mozilla.org/?product=firefox-latest-ssl&os=${ARCH}&lang=ja" \ -O /tmp/firefox.tar.xz && \ tar -xf /tmp/firefox.tar.xz -C /opt/ && \ ln -sf /opt/firefox/firefox /usr/local/bin/firefox ``` 追加で必要な依存は `libdbus-glib-1-2`、`libgtk-3-0`、`libasound2t64`、`xz-utils` です。 **Apple Silicon環境では `linux64-aarch64` を指定する必要があります。**アーキテクチャを判定して切り替える形にしておくと、環境をまたいでも動きます。 ## その他に遭遇した問題 | エラー | 原因 | 解決 | | --- | --- | --- | | `ModuleNotFoundError: No module named 'computer_use'` | `PYTHONPATH=/app` だがパッケージは `/app/src/computer_use/` に配置 | Dockerfileで `ENV PYTHONPATH=/app/src` に変更 | | pyautoguiのXauthority / tkinterエラー | `.Xauthority` が存在しない＋`python3-tk` 未インストール | `python3-tk`、`python3-dev` を追加、entrypoint.shで `touch ~/.Xauthority` | ## macOS前提のコードをLinuxへ移植する 元のコードは完全にmacOS前提（`screencapture`、`osascript`、`pbcopy`等）でした。修正が必要だったのは4ファイルです。 | ファイル | 変更内容 | | --- | --- | | `agent.py` | システムプロンプトをLinux/Firefox/XFCE用に全面書き換え（ctrl系ショートカット、firefox起動方法等） | | `config.py` | スクリーン検出を `osascript` → `xdpyinfo` ＋環境変数フォールバックに変更 | | `computer.py` | スクリーンショット: `screencapture` → `scrot`／クリップボード: `pbcopy` → `xclip`／キーマッピング: cmd → ctrl | | `Dockerfile` | Firefox PPA → 公式バイナリ、xclip / x11-utils等を追加 | 注目すべきは `agent.py` です。**コマンドの置き換えだけでなく、システムプロンプト自体を書き換える必要がありました。**Computer Useでは、プロンプトが環境仕様の説明書になっています。 ## 動作確認：15イテレーションで完了 タスク「**Firefoxでgoogle.comを開いてClaude AIを検索して**」を実行しました。 **結果は成功（15イテレーション、30メッセージ交換で完了）。**エージェントの動作フローは次のとおりです。 1. スクリーンショットでデスクトップ確認 2. `firefox &` でブラウザ起動 3. アドレスバーにgoogle.comを入力 4. 検索ボックスに「Claude AI」を入力 5. 検索結果を確認・スクロール スケーリングについては、**Xvfbの解像度とClaudeの論理解像度が一致（1280x832）するためスケール1.0となり、座標変換の誤差はありませんでした。**解像度を合わせておくと、クリック位置のずれを考えなくて済みます。 ## Computer UseのPoCに向くタスク 公式が推奨する条件は次のとおりです。 - **バッチ処理** - **再試行可能** - **低リスクデータ** - **時間圧力なし** この4条件は、裏返すと**「失敗してもやり直せる範囲で使う」**という意味です。画面操作は環境の変化に弱く、100%の成功は前提にできません。 これを踏まえ、優先度の高いPoC候補として次を整理しています。 1. **レガシーシステムへのデータ入力自動化** 2. **行政ポータルの操作自動化** 3. **競合調査・市場情報収集** いずれも**APIが提供されていない画面が対象**という共通点があります。API連携ができるならそちらが確実です。Computer Useが効くのは、その手段がない領域です。 ## よくある質問 ### Computer Useを動かすには何が必要ですか？ **操作対象となるデスクトップ環境が必要です。**この検証ではDocker上にUbuntu 24.04 + Xvfb + XFCE4 + x11vnc + noVNC + Firefoxを構築しました。 ### 精度を上げるコツはありますか？ **システムプロンプトに環境の制約を明示することです。**「使えるブラウザはFirefoxのみ」「macOSコマンドは使うな」といった指示が効果的でした。エージェントは失敗すると別ブラウザのインストール等に逃げるため、先回りして封じます。 ### Docker内でFirefoxが起動しないのはなぜですか？ **Ubuntu 24.04のfirefoxパッケージがsnap版への移行パッケージで、Dockerコンテナ内ではsnapdが動作しないためです。**Mozilla公式バイナリを直接ダウンロードする方式が最も確実でした。 ### どんな業務に向いていますか？ **バッチ処理・再試行可能・低リスクデータ・時間圧力なし、の4条件を満たすタスクです。**レガシーシステムへのデータ入力、行政ポータルの操作、競合調査などが候補になります。 ## まとめ - Docker（Ubuntu 24.04 + Xvfb + XFCE4 + noVNC）上にComputer Use用のデスクトップ環境を構築 - **「Firefoxでgoogle.comを開いてClaude AIを検索」は15イテレーション・30メッセージ交換で成功** - **システムプロンプトが精度を決める。**環境に合わない指示があるとエージェントが迷走する - Ubuntu 24.04のfirefoxパッケージはsnap移行のため**Docker内では実体がない。Mozilla公式バイナリの直接ダウンロードが確実**（ARM64では `linux64-aarch64`） - Xvfbの解像度とClaudeの論理解像度を一致させる（1280x832）と**スケール1.0で座標変換の誤差なし** - PoC適性は**バッチ処理／再試行可能／低リスクデータ／時間圧力なし**の4条件 Computer Useは、APIが用意されていない画面を自動化する手段です。環境構築とプロンプト設計に手間はかかりますが、他に手がない領域では有力な選択肢になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## MCPサーバーをCloudflare Workersでリモート化する｜プラットフォーム選定の4つの軸 - URL: https://ai-katsu.jp/articles/google-ads-mcp-remote-server - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-05T00:00:00+00:00 - Tools: Google Ads, MCP, Cloudflare - Tasks: 開発・エンジニアリング, ツール検証 - Domain: マーケティング > ローカルMCPの「PCが起動していないと使えない」制約を、Cloudflare Workersへの移行で解消しました。MCPセッションは対話が続くため実行時間制限が最大の分岐点になります。ステートレス設計・JWT二重チェック・ファイルシステム依存ツールの除外という判断をまとめています。 ローカルMCPサーバーは1ファイルで動く手軽さがある一方、**「自分のPC上でしか動かない」という構造的な制約**を持っています。 この検証では、MCPサーバーをCloudflare Workersへ移し、**どこからでも・誰でもGoogle広告データを分析できる状態**を作りました。 > 本記事は3回シリーズの最終回です。第1回で認証設定、第2回でローカルMCPサーバーの構築を扱いました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月5日 | | やりたかったこと | ローカルMCPの制約（PC依存・チーム共有不可・Web版から使えない）を解消する | | 構成 | TypeScript + Hono + @hono/mcp / Cloudflare Workers | | 依存パッケージ | **4つだけ**（hono / @modelcontextprotocol/sdk / @hono/mcp / zod） | | 認証 | **JWT Bearer Token**（有効期限2週間） | | コスト | **無料枠内**（10万リクエスト/日） | ## 結論：ローカルとリモートの違いは通信方式 ``` ローカルMCP: Claude Desktop → (stdio) → ローカルプロセス → Google Ads API ※ 同じPCでしか使えない リモートMCP: Claude Desktop / Web版Claude / Cursor → (HTTP) → クラウドサーバー → Google Ads API ※ どこからでもアクセス可能 ``` **ローカル版はstdio（標準入出力）でプロセス間通信を行うため、同じマシン上でしか動きません。**リモート版はHTTP経由のため、インターネットに接続できるあらゆるクライアントから使えます。 MCPプロトコルが定義するトランスポートは**stdioとStreamable HTTP（SSE）の2つ**で、リモートMCPは後者を使います。 ## プラットフォーム選定：4つの判断軸 3つの候補を比較しました。 | 要件 | Cloudflare Workers | Vercel | Render | | --- | --- | --- | --- | | **SSEストリーミング** | ○ | **△（時間制限）** | ○ | | **コールドスタート** | **ほぼなし** | あり | **大きい** | | 無料枠 | **10万req/日** | 100GB-hrs/月 | 750hrs/月（スリープあり） | | エコシステム | **Hono最適化** | Next.js向き | 汎用 | ### 決め手①：実行時間制限 **MCPセッションではツール呼び出しを含む対話が続くため、ストリーミング接続が維持される時間が最大の分岐点になります。** Vercelは Hobbyプラン10秒 / Proプラン60秒の実行時間制限があり、この制限を超えることは十分にありえます。 ### 決め手②：コールドスタート **MCPクライアントが接続する瞬間のレスポンス速度は、体験に直結します。** Renderの無料プランは**スリープ復帰に10〜30秒**かかり、MCPの接続タイムアウトに引っかかる可能性があります。Workersはエッジ実行のためコールドスタートがほぼゼロです。 ### 決め手③：コスト MCPサーバーの利用パターンは「1日に数十〜数百リクエスト」程度です。**Workers無料枠の10万リクエスト/日は、個人〜小規模チームなら全く問題になりません。** ### 決め手④：エコシステム 技術選定で見逃せない点です。 - **Honoの作者はCloudflare所属。**Workers上での動作が最も安定している - **`@hono/mcp` が提供する `StreamableHTTPTransport` はWorkers前提で設計されている** - 依存パッケージは4つだけで、**Workersのバンドルサイズ制限とも好相性** ## ステートレス設計は制約ではなく健全性 ``` app.all('/mcp', async (c) => { // リクエストごとにMCPサーバーとトランスポートを作成 const mcpServer = createMcpServer(c.env); const transport = new StreamableHTTPTransport(); await mcpServer.connect(transport); return transport.handleRequest(c); }); ``` Cloudflare Workersはリクエストごとに独立した実行コンテキストを持ち、グローバル状態を共有しません。**つまりステートレスに設計せざるを得ない制約があります。** ただしこれは一見すると制約ですが、**実際にはアーキテクチャの健全性を担保してくれます。** 常時起動するサーバーでは、インスタンスの生存管理やメモリリークへの配慮が必要です。**Workersならそもそもその心配がありません。** ## 認証：なぜJWTか リモートMCPサーバーは**公開エンドポイントになるため、認証が必須**です。 | 方式 | 評価 | | --- | --- | | API Key | JWTのほうが安全——**有効期限を設定でき、ペイロードに任意の情報を含められる** | | **JWT** | **採用** | | OAuth2 | 認可サーバーが必要で、個人〜小規模チームには過剰 | さらに**二重チェック**を入れています。 ``` app.use('/mcp', async (c, next) => { const jwtMiddleware = jwt({ secret: c.env.JWT_SECRET }); await jwtMiddleware(c, next); // ソルトの一致チェック（二重チェック） const payload = c.get('jwtPayload'); if (payload.salt !== c.env.JWT_SALT) { return c.json({ error: 'Unauthorized' }, 401); } }); ``` **JWT署名の検証に加え、ペイロード内の `salt` をサーバー側の環境変数と照合します。**トークンは2週間で期限切れになる設定です。 ## Workers環境の制約が理解を深める 実装上、最も学びのあった部分です。 ローカル版はPythonのライブラリがOAuthトークンを自動管理していました。しかし**Workers環境ではNode.jsネイティブのモジュールが使えないため、fetch APIでOAuthトークンを直接更新する**必要があります。 ``` async getAccessToken(): Promise { const response = await fetch('https://oauth2.googleapis.com/token', { method: 'POST', body: new URLSearchParams({ client_id: this.env.GOOGLE_ADS_CLIENT_ID, client_secret: this.env.GOOGLE_ADS_CLIENT_SECRET, refresh_token: this.env.GOOGLE_ADS_REFRESH_TOKEN, grant_type: 'refresh_token' }) }); // アクセストークンをキャッシュ（有効期限5分前に更新） } ``` **ライブラリが隠蔽していたOAuth2のトークン更新フローを自前で実装することで、仕組みが明確になりました。**制約が理解を促した例です。 ## ローカル版との比較 | 観点 | ローカル版 | リモート版 | | --- | --- | --- | | 言語 | Python | TypeScript | | フレームワーク | FastMCP | Hono + @hono/mcp | | 通信方式 | stdio | Streamable HTTP/SSE | | クライアント認証 | なし（ローカルのため不要） | **JWT Bearer Token** | | API Version | v19 | v23 | | ツール数 | 14 | **9** | | **チーム共有** | 不可 | **可能** | | **Web版Claude** | 非対応 | **対応** | | コスト | 無料（自分のPC） | 無料（Workers無料枠） | ツール数が減っている理由は明確です。**ローカルファイルシステムに依存するツール（画像ダウンロード等）を除外したためです。リモートサーバーにはファイルシステムがないので、構造的に不要になります。** ## デプロイ手順 ### 1\. シークレット設定 ``` wrangler secret put GOOGLE_ADS_DEVELOPER_TOKEN wrangler secret put GOOGLE_ADS_CLIENT_ID wrangler secret put GOOGLE_ADS_CLIENT_SECRET wrangler secret put GOOGLE_ADS_REFRESH_TOKEN wrangler secret put JWT_SECRET wrangler secret put JWT_SALT ``` **`wrangler secret put` はCLIから対話形式で値を入力でき、ダッシュボードを開く必要がありません。**コード上では `c.env.GOOGLE_ADS_CLIENT_ID` でアクセスできます。 ### 2\. デプロイ ``` npm run deploy ``` これだけです。**数秒で完了します。** ### 3\. JWTトークン生成 → 4. 接続 ``` { "mcpServers": { "google-ads": { "command": "mcp-remote", "args": [ "https://your-worker-url/mcp", "--header", "Authorization: Bearer your-jwt-token" ] } } } ``` **`mcp-remote` はリモートMCPサーバーへの接続を仲介するプロキシツール**です。Claude Desktopのstdioトランスポートと、リモートサーバーのStreamable HTTPトランスポートの間を橋渡しします。 ## 運用Tips - **`wrangler tail` で本番環境のログをリアルタイムに確認できる**——デバッグ時に重宝する - **ヘルスチェック**：`GET /` でサーバー情報とツール一覧をJSONで返却 - **JWTトークンは2週間で期限切れ**。定期的な再生成が必要 - **`check_token_validity` ツールで、MCPクライアントから直接トークンの有効性を確認できる**——「トークンの状態確認して」と聞くだけ ## シリーズ全体で得られたもの | 回 | 内容 | キーポイント | | --- | --- | --- | | 第1回 | 認証セットアップ | OAuth2クライアント作成、Developer Token取得、テストMCC構築 | | 第2回 | ローカルMCPサーバー構築 | 1ファイルで実装、Claude Desktopから即利用可能 | | 第3回 | リモートMCPサーバー構築 | どこからでもアクセス可能、Web版Claude対応 | 今後の展望としては、**Durable Objectsを活用したセッション管理**（現在はステートレスだが、セッションを維持できれば対話の文脈を跨いだ分析が可能になる）、**書き込み系ツールの段階的な追加**、他のMCPクライアントからの接続検証を挙げています。 ## よくある質問 ### なぜCloudflare Workersを選んだのですか？ **SSEストリーミング対応・コールドスタートの短さ・コスト・Honoエコシステムとの親和性の4点です。**特にMCPセッションは対話が続くため、実行時間制限のあるプラットフォームは不利になります。 ### リモート化すると何ができるようになりますか？ **PCを起動していなくても使え、チームで共有でき、Web版のClaudeからも接続できます。**ローカル版はstdioのため同じマシン上でしか動きません。 ### 認証はどうしていますか？ **JWT Bearer Tokenです。**公開エンドポイントになるため必須になります。署名検証に加えてペイロード内のsaltを環境変数と照合する二重チェックを入れ、有効期限は2週間にしています。 ### ツール数がローカル版より少ないのはなぜですか？ **ローカルファイルシステムに依存するツールを除外したためです。**リモートサーバーにはファイルシステムがないため、画像ダウンロードのようなツールは構造的に不要になります。 ## まとめ - ローカルとリモートの違いは**通信方式（stdio vs Streamable HTTP/SSE）** - プラットフォーム選定の軸は**SSE対応・コールドスタート・コスト・エコシステム** - **MCPセッションは対話が続くため、実行時間制限が最大の分岐点**になる - **ステートレス設計は制約だが、生存管理やメモリリークの心配がなくなる** - 公開エンドポイントになるため**認証は必須。JWT + salt の二重チェック** - **Workers環境の制約が、ライブラリに隠蔽されていたOAuth2の仕組みの理解を促した** - リモート化で**ファイルシステム依存のツールは構造的に不要**になる ローカルで動くものをそのままクラウドに移すことはできません。実行環境の制約に合わせて構成を組み替える過程で、仕組みの理解が深まります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の広告運用・マーケティング業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## MCPサーバーは1ファイルで作れる｜docstringがツール選択の精度を決める - URL: https://ai-katsu.jp/articles/google-ads-mcp-local-server - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-05T00:00:00+00:00 - Models: Claude - Tools: Google Ads, MCP - Tasks: 開発・エンジニアリング, ツール検証 - Domain: マーケティング > Python + FastMCPでGoogle広告のMCPサーバーを構築しました。1ファイル・14ツールで、AIに「過去30日のパフォーマンスを見せて」と聞くだけでデータが返ります。実装より効くのはdocstringの品質。AIが渡す値の揺れを受け側で吸収する設計や、GAQLの注意点もまとめています。 認証を通したら、次はMCPサーバーの実装です。ここは拍子抜けするほど簡単で、**`google_ads_server.py` という1ファイルで完結**します。 この検証では、Python + FastMCPでGoogle広告のMCPサーバーを構築し、**AIに「過去30日のキャンペーンパフォーマンスを見せて」と聞くだけでデータが返る状態**を作りました。 > 本記事は3回シリーズの第2回です。第1回では認証設定、第3回ではリモート化を扱います。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月5日 | | やりたかったこと | 認証基盤の上にMCPサーバーを構築し、Claude DesktopやCursorから自然言語でGoogle広告データを操作する | | 技術スタック | Python 3.11+ / mcp（FastMCP）>= 1.3.0 / google-auth / requests / pydantic | | 実装規模 | **1ファイル・14ツール** | | 接続先 | Claude Desktop / Cursor（stdioトランスポート） | ## 結論：docstringの品質がツール選択の精度を決める FastMCPでは `@mcp.tool()` デコレータを付けるだけで、Python関数がMCPツールとして公開されます。 ``` @mcp.tool() async def list_accounts() -> str: """アクセス可能なすべてのGoogle Adsアカウントを一覧表示します。""" creds = get_credentials() headers = get_headers(creds) url = f"https://googleads.googleapis.com/{API_VERSION}/customers:listAccessibleCustomers" response = requests.get(url, headers=headers) # ... 結果をフォーマットして返す ``` ここで**最も重要なのはdocstringです。**AIはこの説明文を読んで「このツールは何ができるのか」を判断します。 **つまりdocstringの品質が、そのままツール選択の精度に直結します。**実装が正しくても説明が曖昧だと、意図したツールが呼ばれません。 パラメータについても同様で、Pydanticの `Field` に説明を付けます。 ``` @mcp.tool() async def execute_gaql_query( customer_id: str = Field(description="Google Ads顧客ID（10桁、ハイフンなし）"), query: str = Field(description="GAQLクエリ文字列") ) -> str: """カスタムGAQL（Google Ads Query Language）クエリを実行します。""" ``` AIはこのdescriptionを見て、ユーザーの入力からパラメータをマッピングします。 ## 完成イメージ | やりたいこと | AIへの指示例 | 呼ばれるツール | | --- | --- | --- | | アカウント確認 | 「アカウント一覧を表示して」 | `list_accounts` | | パフォーマンス分析 | 「過去30日のキャンペーンパフォーマンスを見せて」 | `get_campaign_performance` | | カスタムクエリ | GAQLを直接指定 | `execute_gaql_query` | | 広告クリエイティブ確認 | 「広告の見出しと説明文を一覧で見たい」 | `get_ad_creatives` | | トークン確認 | 「認証トークンの有効性を確認して」 | `check_token_validity` | **GAQLクエリもAIが組み立てるため、クエリ構文を覚える必要はありません。** ## 提供する14のツール | カテゴリ | ツール | | --- | --- | | **アカウント** | `list_accounts` / `get_account_currency` | | **クエリ・レポート** | `execute_gaql_query` / `run_gaql` / `get_campaign_performance` / `get_ad_performance` / `get_ad_creatives` / `list_resources` | | **アセット** | `get_image_assets` / `download_image_asset` / `get_asset_usage` / `analyze_image_assets` | | **認証** | `check_token_validity` / `refresh_access_token` | 実際に使うと、**ほとんどのケースは `list_accounts` → `get_campaign_performance` のワークフローか、`run_gaql` でカスタムクエリを投げるパターンに集約されます。** ツールを14個用意しても、日常的に使われるのは数個です。それでも網羅しておくと、AIが状況に応じて選べます。 ## 認証は2方式を切り替え可能に 環境変数 `GOOGLE_ADS_AUTH_TYPE` で切り替えます。 | 方式 | 用途 | 特徴 | | --- | --- | --- | | **OAuth 2.0**（デフォルト） | 個人ユーザー向け | トークンファイルから読み込み、期限切れなら自動リフレッシュ、無ければブラウザ認証 | | **サービスアカウント** | 自動化システム向け | JSONキーから認証。**ドメイン委任にも対応** | ``` def get_oauth_credentials(): """OAuthユーザー認証情報を取得・更新します。""" creds = None token_path = GOOGLE_ADS_CREDENTIALS_PATH if os.path.exists(token_path): creds = Credentials.from_authorized_user_info(creds_data, SCOPES) if not creds or not creds.valid: if creds and creds.expired and creds.refresh_token: creds.refresh(Request()) # 自動リフレッシュ else: flow = InstalledAppFlow.from_client_config(client_config, SCOPES) creds = flow.run_local_server(port=8080) return creds ``` ## 地味にハマる：顧客IDのフォーマット 実運用で効いてくる細部です。 **ユーザーはハイフン付き・引用符付きなど、さまざまな形式で顧客IDを入力してきます。**そこで正規化関数を用意しています。 ``` def format_customer_id(customer_id: str) -> str: customer_id = str(customer_id) customer_id = customer_id.replace('\\"', '').replace('"', '') customer_id = ''.join(char for char in customer_id if char.isdigit()) return customer_id.zfill(10) ``` `123-456-7890` でも `"1234567890"` でも、すべて `1234567890` に正規化されます。 **AIが渡してくる値の揺れを吸収する関数です。**人間相手なら「ハイフンなしで入力してください」と書けますが、AI経由では入力形式を制御できません。受け側で吸収する必要があります。 ## GAQLで知っておくべき3点 ``` SELECT campaign.name, metrics.clicks, metrics.impressions, metrics.cost_micros FROM campaign WHERE segments.date DURING LAST_30_DAYS ORDER BY metrics.cost_micros DESC LIMIT 50 ``` - **`cost_micros` は100万分の1単位**——`1,000,000` = 1通貨単位 - **日付フィルタは定数が使える**——`DURING LAST_7_DAYS`、`DURING LAST_30_DAYS` など - **出力形式を切り替えられる**——`run_gaql` なら table / json / csv SQLとの違いとして、**JOINが不要**（リソース間の関係はAPI側で解決される）、**`*` によるワイルドカード選択ができない**点があります。 ただし細かい構文を覚える必要はほとんどありません。「過去7日間でクリック数が多い順にキャンペーンを表示して」と伝えれば、AIが適切なクエリを生成します。 ## 接続設定 stdioトランスポートで起動するため、クライアント側がプロセスを直接起動して通信します。 ``` if __name__ == "__main__": mcp.run(transport="stdio") ``` Claude Desktopの場合は設定ファイルに追記します。 ``` { "mcpServers": { "google-ads": { "command": "python", "args": ["/path/to/mcp-google-ads/google_ads_server.py"], "env": { "GOOGLE_ADS_AUTH_TYPE": "oauth", "GOOGLE_ADS_CREDENTIALS_PATH": "/path/to/google_ads_token.json", "GOOGLE_ADS_DEVELOPER_TOKEN": "your-developer-token", "GOOGLE_ADS_LOGIN_CUSTOMER_ID": "your-mcc-id" } } } } ``` Cursorの場合は Settings → MCP から「Add new MCP server」で、Typeを command、Commandに実行パスを指定します。 ## テストMCCでの動作確認手順 Developer TokenがPending状態でも、以下の順で確認できます。 1. **`list_accounts`** — テストMCC配下のアカウントIDが表示されればOK 2. **`get_account_currency`** — `JPY` や `USD` が返れば正常 3. **`get_campaign_performance`** — **テストMCCにはキャンペーンがないので空データが返るが、エラーが出なければAPI通信は成功** 本番承認後は、**`GOOGLE_ADS_LOGIN_CUSTOMER_ID` を本番MCCのIDに切り替えるだけで移行完了**です。 ## ローカルMCPサーバーの限界 1ファイルで実用的なものが作れる一方、構造的な課題があります。 - **PCが起動していないと使えない**——ローカルプロセスのため、外出先からは使えない - **チーム共有ができない**——各メンバーが個別にセットアップする必要がある - **認証情報の管理**——各端末に `.env` やトークンファイルを置く必要がある **個人利用なら十分ですが、組織で使うとなると別の構成が必要になります。**次回はこれをリモート化します。 ## よくある質問 ### MCPサーバーの実装は難しいですか？ **1ファイルで完結します。**FastMCPの `@mcp.tool()` デコレータを付けるだけで、Python関数がMCPツールとして公開されます。 ### 意図したツールが呼ばれません **docstringを見直してください。**AIはdocstringを読んでツールを選択するため、説明の品質がそのまま選択精度になります。パラメータもPydanticの `Field` にdescriptionを付けます。 ### GAQLの構文を覚える必要がありますか？ **ほとんど不要です。**「過去7日間でクリック数が多い順に」と伝えれば、AIが適切なクエリを生成します。ただし `cost_micros` が100万分の1単位である点は知っておくと解釈を誤りません。 ### 顧客IDでエラーになります **入力形式の揺れを吸収する正規化関数を用意してください。**AI経由では入力形式を制御できないため、ハイフンや引用符を除去して10桁ゼロ埋めする処理を受け側に置きます。 ## まとめ - MCPサーバーは**1ファイル・14ツールで実用的なものが作れる** - **docstringの品質がツール選択の精度に直結する**。実装より説明が効く - 認証は**OAuthとサービスアカウントの2方式**を環境変数で切り替え - **AIが渡す値の揺れは受け側で吸収する**（顧客IDの正規化） - GAQLは**JOIN不要・ワイルドカード不可**。`cost_micros` は100万分の1単位 - 実際に使われるのは**14ツールのうち数個**に集約される - ローカル構成の限界は**PC依存・チーム共有不可・認証情報の分散** AIに外部APIを触らせる仕組みでは、機能の多さより「AIが正しく選べるか」が実用性を決めます。説明文の設計が実装と同じくらい重要になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の広告運用・マーケティング業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## シェルスクリプトから呼べるブラウザ自動化｜browser-use CLI 2.0の実測 - URL: https://ai-katsu.jp/articles/browser-use-cli-2 - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-05T00:00:00+00:00 - Models: Claude - Tools: Browser Use, MCP - Tasks: リサーチ・データ収集, ツール検証 > 公式サイトのニュース収集という実業務タスクでbrowser-use CLI 2.0を検証しました。CLIで使えるためシェルスクリプトに組み込みやすく、LLM統合・MCP対応・セッション管理が標準装備。一方でボット対策サイトには30秒待機が必要で、リアルタイム処理には向きません。 ブラウザ自動化ツールは以前から存在しますが、**LLM統合が標準搭載され、CLIから直接使える**となると位置づけが変わります。 この検証では、公式サイトからのニュース収集という実業務タスクで使えるかを確認しました。**実用レベルで動作した一方、ボット対策サイトでは手動待機が必要**という制約も見えています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年4月5日 | | 対象 | browser-use CLI 2.0（v0.12.6）／MITライセンス | | やりたかったこと | 公式サイトのニュース・ブログ記事を定期収集し、ボット対策サイトにもアクセスする | | 結果 | **ニュース抽出タスクは実用レベル。日付フィルタリングも正確に動作** | | 削減効果 | **週5時間**（手動ニュース確認作業） | | 費用 | 0円（OSS） | ## 結論：シェルスクリプトから呼べることが強み 他のブラウザ自動化ツールとの差を整理すると、こうなります。 | 項目 | browser-use CLI | Playwright | Selenium | | --- | --- | --- | --- | | 提供形態 | **CLI + Python API** | Python API | 複数言語対応 | | **LLM統合** | **ネイティブ対応** | なし | なし | | **MCP対応** | **あり** | なし | なし | | **セッション管理** | **CLI標準機能** | 手動実装必要 | 手動実装必要 | **CLIで使えるため、シェルスクリプトから呼び出しやすくなります。**Pythonのコードを書かずに、既存の自動化フローへ組み込めます。 セッション管理が組み込まれている点も実務的です。**複数の並行実行を、自前の実装なしで扱えます。** ## 実測したパフォーマンス | 項目 | 測定結果 | | --- | --- | | ページ読み込み速度 | 3〜5秒 | | HTML取得時間 | 2〜3秒 | | スクリーンショット取得 | 1〜2秒 | | **ニュース抽出（全体）** | **30〜60秒** | | **ボット対策サイト対応** | **60〜90秒**（30秒待機含む） | この数値から言えることがあります。 **長時間タスクは30〜120秒かかるため、リアルタイム処理には不向きです。**定期実行やバッチ処理に向いた特性になります。 ## ボット対策サイトへの対応 この検証の目的の1つでした。 **headedモード（ブラウザを表示する形式）であれば、ボット対策のあるサイトにもアクセスできました。** ただし条件があります。**headlessモードではブロックされる可能性があり、対策として30秒の待機が必要です。** この30秒が自動化の設計に影響します。**「アクセスできる」ことと「自動で回せる」ことの間に、待機時間という制約が入ります。** ## 実装の基本形 この検証で確認できた組み合わせです。 - **HTML取得 → HTMLパーサーで解析**という流れが安全に実行できる - 取得したHTMLは**完全なDOM**で、パースに最適な形式 - **日付フィルタリングも正確に動作** - **重複除去により精度が向上** ニュース収集では、同じ記事が複数箇所からリンクされていることがあります。**重複除去を入れるかどうかで、結果の使いやすさが変わります。** ## 運用上の注意点 ### セッションのクリーンアップ **セッションのクリーンアップを手動で行う必要があり、忘れるとブラウザプロセスが残ります。** 対処は `try-finally` で確実に終了処理を通すことです。 **自動化スクリプトでは、途中でエラーが起きても後始末が実行される構造にしておく**必要があります。放置するとプロセスが積み上がります。 ### 環境要件 **Python 3.11以上が必須で、3.10以下では動作しません。**環境制約はやや厳しめです。 ## 懸念点 - **Python 3.11以上必須**（環境制約が厳しい） - 比較的新しいツールのため、情報が少ない - **ボット対策は手動待機が必要**（自動化に課題） - セッションクリーンアップを忘れるとプロセスが残る ## 導入コストと効果 | 項目 | 内容 | | --- | --- | | 初期設定時間 | **15分**（インストール〜初回実行） | | 学習時間 | 2〜3時間（基本操作習得〜サンプル実装） | | 費用 | **0円**（OSS）＋ Agent API使用時のみLLM従量課金 | | **削減効果** | **週5時間**（手動ニュース確認作業） | **初期設定15分に対して週5時間の削減**という試算です。無料ツールのため、実質的に即時回収になります。 ## 操作コマンド 基本的な操作は直感的です。 - `open [URL]` — ブラウザを起動してURLを開く - `state` — 現在ページの状態（クリック可能要素等）を取得 - `screenshot [PATH]` — スクリーンショット保存 - `get html` / `get title` — ページ情報の取得 - `click [INDEX]` / `type [TEXT]` — 要素操作 - `close` — セッション終了 加えて、セッション名の指定やheadedモードの切り替えもフラグで行えます。 **CLIコマンドがシンプルで、エラーメッセージも分かりやすい**という評価です。 ## よくある質問 ### Playwrightと何が違いますか？ **CLIで使えることと、LLM統合・MCP対応・セッション管理が標準で備わっていることです。**シェルスクリプトから呼び出しやすく、既存の自動化フローに組み込めます。 ### リアルタイム処理に使えますか？ **向いていません。**長時間タスクは30〜120秒かかります。定期実行やバッチ処理に適した特性です。 ### ボット対策のあるサイトにアクセスできますか？ **headedモードであれば可能ですが、30秒程度の待機が必要になります。**headlessモードではブロックされる可能性があります。 ### プロセスが残ってしまいます **セッションのクリーンアップが手動のためです。**`try-finally` で確実に終了処理を通す構造にしてください。 ## まとめ - 強みは**CLIで使えること**。シェルスクリプトから呼び出せ、既存フローに組み込みやすい - **LLM統合・MCP対応・セッション管理が標準**。自前実装が不要 - ニュース抽出は**30〜60秒。リアルタイム処理には不向き**で、定期実行向き - ボット対策サイトは**headedモード＋30秒待機**で通るが、自動化設計に影響する - **セッションのクリーンアップは手動。**`try-finally` で確実に通す - 初期設定15分・費用0円に対し、**週5時間の削減**という試算 自動化ツールの選定では、機能の多さより「既存のフローに組み込めるか」が効いてきます。CLIから呼べるかどうかは、その点で大きな差になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の情報収集・業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Google広告APIをAIにつなぐ｜認証で詰まる2つの罠と6種類の認証情報 - URL: https://ai-katsu.jp/articles/google-ads-mcp-auth - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-05T00:00:00+00:00 - Models: Claude - Tools: Google Ads, MCP - Tasks: 開発・エンジニアリング, ツール検証 - Domain: マーケティング > AIから自然言語でGoogle広告のデータを引ける状態をMCPサーバーで作りました。ただし最大の壁は実装ではなく認証です。必要な認証情報は6種類、取得場所はGCPと広告管理画面に分散。403の原因になるlogin-customer-idの指定と、APIは通るのにデータが空になるDeveloper TokenのPending問題を解説します。 Google広告を運用していると、毎日のように管理画面へログインしてデータを確認する作業が発生します。「過去30日のキャンペーンパフォーマンスはどうだったか」「先週CPAが高かったキャンペーンはどれか」——そのたびにブラウザを開き、フィルタをかけ、期間を設定する。 この検証では、**AIから自然言語でGoogle広告APIを叩ける状態**をMCPサーバーで実現しました。ただし最大の壁は実装ではありません。**認証を通すほうが、MCPサーバーのコードを書くより10倍大変でした。** > 本記事は3回シリーズの第1回です。第2回でローカルMCPサーバーの構築、第3回でリモートMCPサーバーの構築を扱います。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年4月5日 | | やりたかったこと | AIに「過去30日のキャンペーンパフォーマンスを見せて」と聞くだけで、Google広告APIからデータが返る状態をつくる | | 使用技術 | MCP（Model Context Protocol）／Google Ads API v19／OAuth 2.0 | | 本記事の範囲 | **認証まわりのセットアップ**（最初にして最大の壁） | | 必要な認証情報 | **6種類** | ## 結論：詰まるのは実装ではなく認証 Google広告APIの認証は、必要なものが多く、手順も長く、**エラーメッセージが分かりにくい**という三重苦があります。 特に厄介なのが次の2点です。どちらも「設定は正しいのに動かない」ように見えます。 - **`login-customer-id` に何を指定するか**——間違えると403 - **Developer Tokenの Pending 状態**——APIは通るのにデータが空で返る 後述しますが、この2つを知っているかどうかで所要時間がまったく変わります。 ## MCPとは MCP（Model Context Protocol）は、Anthropic社が提唱したオープン標準プロトコルです。よく**「AIアプリケーションのためのUSB-Cポート」**と表現されます。 USB-Cがどんなデバイスでも同じポートで接続できるように、**MCPはどんな外部サービスでも同じプロトコルでAIにつなげられる**という思想です。 ``` Claude / Cursor（AIクライアント） ↕ MCP プロトコル MCPサーバー ↕ 外部API（Google広告 API など） ``` 2026年現在、MCPのエコシステムは急速に広がっています。Web版のClaudeからもMCPサーバーに接続でき、VS Codeとの統合も進んでいます。パッケージマネージャで公開されたMCPサーバーを1クリックでインストールできる環境も整いつつあります。 ## 必要な認証情報は6種類 | # | 必要なもの | 取得場所 | | --- | --- | --- | | 1 | GCPプロジェクト | Google Cloud Console | | 2 | Google Ads APIの有効化 | GCPのAPIライブラリ | | 3 | OAuth同意画面の設定 | GCPの認証情報 | | 4 | OAuthクライアントID（client\_id + client\_secret） | GCPの認証情報 | | 5 | **デベロッパートークン** | **Google広告管理画面**（GCPではない） | | 6 | リフレッシュトークン | OAuth認証フロー | 取得場所が**GCPとGoogle広告管理画面の2箇所に分かれている**点が、最初の混乱ポイントです。 ``` GCPプロジェクト作成 ↓ Google Ads API有効化 ↓ OAuth同意画面設定 ↓ OAuthクライアントID作成 → client_id + client_secret取得 ↓ Developer Token取得（Google広告管理画面のAPIセンター） ↓ 認可コード取得（ブラウザでOAuth認証） ↓ リフレッシュトークン発行（curlでトークン交換） ↓ API動作確認（curlで直叩き） ``` ## Step 1〜3：GCP側の設定 Google Cloud Consoleで新規プロジェクトを作成し、「APIとサービス」→「ライブラリ」から **Google Ads API を有効化**します。 次にOAuth同意画面を設定します。ポイントは3つです。 - **ユーザータイプ**: 「外部」を選択 - **スコープ**: `https://www.googleapis.com/auth/adwords` を追加 - **テストユーザー**: 自分のGoogleアカウントのメールアドレスを追加 **テストユーザーの追加を忘れると、認証時に「このアプリはアクセスできません」というエラーが出ます。**見落としやすい項目です。 続いて「認証情報を作成」→「OAuthクライアントID」で、アプリケーションの種類に**「デスクトップアプリ」**を選択します。作成すると client\_id と client\_secret が表示されるので控えておきます（JSONでダウンロードも可能）。 ## Step 4：Developer Tokenの取得 ここが特殊です。**Developer TokenはGCPではなく、Google広告の管理画面から取得します。** Google広告にログインし、「ツールと設定」→「APIセンター」に進むと、**22文字の英数字トークン**が表示されます。 そして重要な注意点があります。 - **最初に発行されるDeveloper Tokenは Pending（テスト）状態** - **Pending状態では、テストMCCアカウント配下でしか動作しない** - 本番のGoogle広告アカウントにアクセスするには**本番承認（Standard Access）が必要** - **承認には通常1〜3営業日かかる** **承認待ちの時間が発生するため、早めに申請しておくことが重要です。**実装が終わってから申請すると、そこで足止めされます。 ## Step 5：リフレッシュトークンの発行 ### ① 認可コードの取得 次のURLをブラウザで開きます（`your-client-id` は取得した client\_id に置き換え）。 ``` https://accounts.google.com/o/oauth2/auth?client_id=your-client-id.apps.googleusercontent.com&redirect_uri=http://localhost&scope=https://www.googleapis.com/auth/adwords&access_type=offline&response_type=code ``` ログインしてアクセスを許可すると `http://localhost` にリダイレクトされます。 ここで戸惑いやすい点があります。**localhostにサーバーが立っていないため、ブラウザには「サイトに到達できません」と表示されます。**しかし問題ありません。**アドレスバーのURLに含まれる `code=` の値が認可コードです。** ``` http://localhost/?code=4/0Axxxxxxxxxxxxxxxxxxxxxxxx&scope=... ``` ### ② トークン交換 ``` curl \ --data "grant_type=authorization_code" \ --data "client_id=your-client-id.apps.googleusercontent.com" \ --data "client_secret=your-client-secret" \ --data "redirect_uri=http://localhost" \ --data "code=取得した認可コード" \ https://www.googleapis.com/oauth2/v3/token ``` 成功すると次のようなレスポンスが返ります。 ``` { "access_token": "ya29.xxxxx...", "expires_in": 3599, "refresh_token": "1//0exxxxx...", "scope": "https://www.googleapis.com/auth/adwords", "token_type": "Bearer" } ``` **`refresh_token` の値を必ず保存してください。**access\_tokenは1時間で期限切れになりますが、refresh\_tokenがあれば何度でも再発行できます。 ## Step 6：curlで動作確認 アカウント一覧の取得で疎通を確認します。 ``` curl -f --request GET \ "https://googleads.googleapis.com/v19/customers:listAccessibleCustomers" \ --header "Content-Type: application/json" \ --header "developer-token: your-developer-token" \ --header "Authorization: Bearer your-access-token" ``` さらにGAQL（Google Ads Query Language）でキャンペーン一覧も取得できます。 ``` curl -i -X POST \ "https://googleads.googleapis.com/v19/customers/your-customer-id/googleAds:searchStream" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer your-access-token" \ -H "developer-token: your-developer-token" \ -H "login-customer-id: your-mcc-id" \ --data '{ "query": "SELECT campaign.id, campaign.name FROM campaign ORDER BY campaign.id" }' ``` ## ハマりポイント①：`login-customer-id` の罠 GAQLクエリを投げる際、ヘッダーに `login-customer-id` を指定します。MCC（マネージャーアカウント）配下のクライアントアカウントを操作する場合です。 ここで**クライアントアカウントのIDを指定すると `403 Forbidden` になります。** | 指定箇所 | 入れるID | | --- | --- | | **`login-customer-id` ヘッダー** | **MCCのID** | | URLパスの `customers/{customer-id}` | 操作対象のクライアントアカウントID | **`login-customer-id` は「どのMCCとしてログインするか」を示すヘッダー**です。操作対象を指定するものではありません。 ## ハマりポイント②：Pending Developer Tokenの壁 こちらのほうが厄介です。**APIは正常に通るのに、データが空で返ります。** 原因はDeveloper TokenのPending状態です。 - Pending状態では**テストMCCアカウント配下でしか動作しない** - **テストMCCと本番MCCは完全に分離されている。**テストMCCに本番のクライアントアカウントを紐づけることはできない - **テストMCC自体にキャンペーン等のデータが存在しない** つまり**「APIは通っているのにデータが返ってこない」状態は、何も間違っていません。**テストMCCにデータがないだけです。 ここで実装を疑い始めると、原因のない場所を延々と探すことになります。 ### 本番承認後の切り替え 本番承認（Standard Access）が下りたら、以下を切り替えます。 - `login-customer-id` → **本番MCCのID** - URLの `customers/{id}` → **本番クライアントアカウントのID** ## よくある質問 ### MCPとは何ですか？ **AIと外部APIをつなぐオープン標準プロトコルです。**「AIアプリケーションのためのUSB-Cポート」と表現されます。どんな外部サービスでも同じプロトコルでAIに接続できます。 ### Developer Tokenはどこで取得しますか？ **GCPではなく、Google広告の管理画面（ツールと設定 → APIセンター）です。**22文字の英数字が表示されます。 ### APIは成功するのにデータが空です **Developer TokenがPending状態の可能性が高いです。**Pending状態ではテストMCC配下でしか動作せず、テストMCCにはデータが存在しません。実装は正しい可能性があります。本番承認には1〜3営業日かかります。 ### 403エラーが出ます **`login-customer-id` にクライアントアカウントのIDを指定していないか確認してください。**ここにはMCCのIDを入れ、操作対象はURLパスの `customers/{id}` で指定します。 ## まとめ - MCPサーバーは**コードを書くより認証を通すほうが大変**だった - 必要な認証情報は**6種類**。取得場所がGCPとGoogle広告管理画面に分かれている - **Developer TokenはGoogle広告管理画面から取得**（22文字）。最初はPending状態 - **Pending状態ではテストMCC配下のみ。データが空で返るのは正常** - **本番承認には1〜3営業日。**実装前に申請しておく - **`login-customer-id` にはMCCのIDを入れる。**クライアントIDを入れると403 - 認可コードは**リダイレクト先がエラー表示でもURLから取得できる** 外部APIとの連携では、認証の設計と承認フローが実装より重くなることがあります。承認待ちが発生する要素は、先に申請してから開発に入ると止まりません。 次回は、この認証情報を使って **Python + FastMCP でMCPサーバーを実装**します。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の広告運用・マーケティング業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AI駆動開発の環境をゼロから作る｜Claude Code + GitHub + Vercel（macOS/Windows対応） - URL: https://ai-katsu.jp/articles/claude-code-github-vercel-intro - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-05T00:00:00+00:00 - Models: Claude Code - Tools: GitHub, Vercel - Tasks: 開発・エンジニアリング, ツール検証 > 環境構築から本番公開・運用までを一続きで解説します。AIに実装を任せるほど、安全に止める仕組みの価値が上がります。ブランチ保護でよくある設定ミス、プランモードで手戻りを減らす方法、AIが触れない領域の切り分けまでまとめました。Windows手順も含みます。 AIにコードを書かせるだけなら、ツールを入れれば今日から始められます。しかし**それを本番公開まで安全に運べる状態にする**には、いくつかの設定が必要です。 この記事では、**環境構築から本番公開・運用まで**を一続きで解説します。macOSとWindowsの両方の手順を含みます。 ## この記事の概要 | 項目 | 内容 | | --- | --- | | 構成 | Claude Code + GitHub + Vercel | | 範囲 | **環境構築 → リポジトリ保護 → 設計 → CI/CD → 本番公開 → 運用** | | 対応OS | macOS / Windows（**差分はSTEP 1のみ**） | ## 結論：役割を3つに分けて理解する | ツール | 役割 | | --- | --- | | **Claude Code** | AI搭載の開発アシスタント（**実装・PR作成まで担う**） | | **GitHub** | コードの管理・品質チェックの場所 | | **Vercel** | 本番サイトを公開・運用する場所 | ``` 開発者のPC [Claude Code] ←── AIが実装・PR作成を支援 ↓ git push GitHub ・コードの保管場所 ・PRのレビュー・マージ ・テスト自動実行 / 脆弱性の自動検知 ↓ mainにマージ → 自動デプロイ Vercel ・ホスティング ・PRごとにプレビューURLを自動生成 ・カスタムドメイン・SSL自動発行 ``` ## STEP 1：環境構築 ### macOSの場合（3つ） ``` # Node.js v22 の確認（22.x.x と表示されればOK） node -v # GitHub CLI brew install gh gh auth login # Claude Code npm install -g @anthropic-ai/claude-code ``` ### Windowsの場合（4つ） Windowsでは **winget**（Windows標準のパッケージ管理ツール）を使うのが最も手軽です。**macOSのHomebrewに相当し、Windows 10 21H1以降・Windows 11に標準搭載**されています。 ターミナルは標準搭載の**PowerShell**を使います。 ``` winget install Git.Git winget install OpenJS.NodeJS.LTS winget install GitHub.cli ``` **Windowsでは Git for Windows のインストールが追加で必要**です（macOSには標準で入っています）。 もう1点、重要な注意があります。**各インストール後はPowerShellを再起動してからバージョン確認してください。**再起動しないとPATHが反映されません。 **STEP 2以降はmacOSとWindowsで共通です。** ## STEP 2：リポジトリを「守る」設定 リポジトリを作っただけでは、**誰でも（自分でも）mainブランチに直接pushできてしまいます。**安全レールがない状態です。 ``` 【危険な状態（設定なし）】 開発者 → main に直接 push → 即座に本番へ反映 ↑ バグがあっても止まらない 【安全な状態（設定あり）】 開発者 → feature ブランチ → PR 作成 → CI チェック → マージ → 本番へ反映 ↑ ここで問題を検知できる ``` ### mainブランチ保護（Rulesets） | 設定 | 値 | 意味 | | --- | --- | --- | | **Enforcement status** | **Active** | **これがDisabledだとルールが一切効かない** | | Target branches | `main` | 保護対象 | | Require a pull request | ON | PR経由でないとマージ不可 | | Require status checks to pass | ON（任意） | CIが通らないとマージ不可 | | Block force pushes | ON | 強制上書き禁止 | **Enforcement status を Active にするのを忘れないでください。**Disabledで作成すると設定が全て無効になります（実際によくあるミスです）。 あわせて**Dependabotの有効化**と、**マージ戦略をSquash mergeに統一**する設定も行います。 ## STEP 3：プランモードで設計する Claude Codeの最大の特徴は**「実装前に設計を合意してから動く」**プランモードです。 - 実装方針を**複数の選択肢で提示**してくれる - **「どのアプローチにしますか？」と確認してから**実装を始める - 設計の記録をファイルに保存する 実際のやりとりは次のような形です。 ``` ユーザー: サービス紹介ページを追加したい Claude Code: 以下の3点について確認させてください。 1. ページ構成：シングルページ vs. カテゴリ別複数ページ 2. デザイン：既存デザインに合わせる vs. 新規デザイン 3. コンテンツ：静的テキスト vs. CMSで管理 ユーザー: シングルページ、既存デザイン、静的テキスト Claude Code: 了解です。では実装を開始します... ``` **実装の前に方針を合意するので、「作ってみたら思ってたのと違う」という手戻りが大幅に減ります。** ### 担当範囲の切り分け | Claude Codeが担う | 人間が担う（AIが触れない領域） | | --- | --- | | コードの実装 | **GitHub・VercelのGUI操作** | | テストの作成 | **sudoが必要なOS権限操作** | | PRの自動作成 | **最終的なマージの判断** | | エラーの調査と修正提案 | — | **ブラウザ上の設定操作は、AIが代替できない領域として残ります。** ## STEP 4：CI/CD（任意・推奨） 最初はスキップしても本番公開はできます。ただしリスクを把握したうえで判断してください。 | リスク | 内容 | | --- | --- | | バグがmainに入る | テストを手動で実行し忘れると気づかない | | Dependabot PRの品質が不明 | 自動作成されたPRが問題ないか確認できない | | **後から導入が大変** | **チームが増えると後付けコストが跳ね上がる** | 導入は最小構成なら1ファイルで済みます。 ``` name: CI on: push: branches: [main] pull_request: branches: [main] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '22' - run: npm ci - run: npm run test # テストが通らないとマージ不可 - run: npm run build # ビルドが通らないとマージ不可 ``` ## STEP 5：本番公開 GitHubと連携するだけで、**mainへのマージが自動で本番反映**になります。 1. Vercelにアクセス → GitHubでログイン 2. 「Add New Project」→ リポジトリを選択 3. **フレームワークが自動検出される** あわせて環境変数の設定、**PRごとのプレビューデプロイ**、カスタムドメインの紐付けを行います。 ## STEP 6：運用は常にPR経由 ``` # 1. ブランチを作る # 2. Claude Code で実装 # → 実装・テストを行い、PRを自動作成 # 3. GitHub でマージ # → Vercel が自動でデプロイ ``` **この流れが固定されていれば、AIが実装しても本番が壊れません。**保護設定とCIが、間に入って止めてくれます。 ## よくある質問 ### Windowsでも同じ手順でできますか？ **差分はSTEP 1（環境構築）のみです。**Windowsではwingetを使い、Git for Windowsのインストールが追加で必要になります。STEP 2以降は共通です。 ### ブランチ保護の設定が効きません **Enforcement status が Active になっているか確認してください。**Disabledで作成すると設定が全て無効になります。よくあるミスです。 ### CI/CDは必須ですか？ **任意ですが推奨です。**スキップしても本番公開はできます。ただしチームが増えてからの後付けはコストが跳ね上がります。 ### AIに任せられない作業は何ですか？ **GitHub・VercelのGUI操作、sudoが必要なOS権限操作、最終的なマージの判断です。**ブラウザ上の設定は人間が担当します。 ## まとめ - 役割は**Claude Code（実装）／GitHub（管理・品質）／Vercel（公開）**の3分担 - 環境構築の**OS差分はSTEP 1のみ**。WindowsはwingetとGit for Windowsが追加 - Windowsは**インストール後にターミナルを再起動**しないとPATHが反映されない - **リポジトリ保護のEnforcement statusをActiveにする**——Disabledだと全て無効 - プランモードで**実装前に方針を合意**すると手戻りが減る - **GUI操作・OS権限操作・マージ判断は人間の担当**として残る - CI/CDは任意だが、**後付けはコストが跳ね上がる** AIに実装を任せるほど、安全に止める仕組みの価値が上がります。保護設定とCIを先に入れておけば、あとは流れに乗せるだけになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Claude Codeで設計から本番公開まで3時間｜イシュー駆動＋TDD＋Cloudflare Pagesの実践記録 - URL: https://ai-katsu.jp/articles/claude-code-hp-development - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-04-05T00:00:00+00:00 - Models: Claude Code - Tools: Astro, Cloudflare, GitHub - Tasks: 開発・エンジニアリング, ツール検証 > Claude Codeで「プランニング → イシュー作成 → TDD実装 → PR作成・マージ → デプロイ → DNS設定」の全工程を1日で実行しました。Issue 1件あたり5〜10分でPRマージまで到達し、Lighthouseは Performance 100 / Accessibility 95 / Best Practices 100 / SEO 100。security-auditorエージェントがMXレコード不足とDMARC未設定を事前検出した経緯もまとめています。 AIコーディングツールの評価は、コードが書けるかどうかで止まりがちです。しかし実務で効くのは、**設計からデプロイまでを止まらずに通せるか**です。 この検証では、Claude Codeで「プランニング → イシュー作成 → TDD実装 → PR作成・マージ → デプロイ → DNS設定」の全工程を実行しました。**プランニング開始から本番公開まで約3時間、Lighthouseは Performance 100 / Accessibility 95 / Best Practices 100 / SEO 100** という結果です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証日 | 2026年4月5日（1日で完結） | | 使用ツール | Claude Code（Claude Opus 4.6・1Mコンテキスト）／GitHub CLI（gh）／Cloudflare Pages（Free） | | 技術スタック | Astro 6 + React Islands + TailwindCSS 4 / TypeScript 5.x / Zod / @astrojs/cloudflare / Vitest | | 検証対象 | Claude Codeを活用したHP制作〜公開の一気通貫ワークフロー | | 全体所要時間 | **約3時間**（プランニング開始〜本番公開） | | 判定 | **即座に導入推奨**（★5/5） | ## 結論：Issue 1件あたり5〜10分でPRマージまで到達 最も効いたのはイシュー駆動開発のサイクルです。 **gh issue create / gh pr create / gh pr merge を連続実行し、Issue作成 → 実装 → PR → マージの1サイクルが5〜10分で完了。5件のIssueを約30分で全て処理しました。** ここでの要点は、コード生成が速いことではありません。**GitHubの操作までツール側で完結するため、作業の切れ目が発生しない**という点です。 通常の開発では、実装が終わるたびにブラウザでGitHubを開き、PRを作り、マージし、ローカルに戻る——という往復が入ります。この切り替えが1日に何度も積み重なります。gh CLI連携があると、この往復が消えます。 ## 実績タイム | 工程 | 所要時間 | | --- | --- | | リポジトリ作成〜初期コミット | 約15分 | | Issue 5件（型拡張／ページ新設／ナビ／リンク／アナリティクス）の実装完了 | **約30分** | | Cloudflareアダプタ切替〜カスタムドメイン設定完了 | 約60分 | | **全体（プランニング開始〜本番公開）** | **約3時間** | 手動で行えば2〜3日はかかる作業量です。**削減効果は手動開発比で約60〜70%と試算しています。** ## プランモード：設計を先に確定させる 実装前にプランファイルを作成し、方針をすり合わせる工程です。 この検証では、AskUserQuestionで**3つの選択肢（カテゴリ構成・ページ構成・サービス名表現）を同時に提示**し、方針を決めました。あわせて**Webサーチエージェントで市場相場を自動調査し、料金プランの根拠を提供**しています。 **プランモードは「設計 → 確認 → 実装」の流れを強制するため、手戻りが少なくなります。**AIに実装させるとき、方針が固まらないまま書き始めると、後から大きく直すことになります。 ## TDD：テスト先行を厳密に回す 実装はテスト先行（Red → Green → Refactor）で進めました。1サイクルの実行フローは次のとおりです。 ``` 1. git checkout -b feat/service-data-model 2. テスト作成（tests/data/services.test.ts）→ Red確認 3. 型拡張 + データ定義 → Green確認 4. npx astro check → 型エラー0件 5. git add → git commit → git push 6. gh pr create → gh pr merge --squash 7. git checkout main → git pull ``` 結果は**テスト13件全通過、型エラー0件**。**vitestのパスエイリアス設定やtsconfig.jsonのexclude修正など、テスト基盤の整備も自動で対応**しています。 ## セキュリティ監査エージェントがDNS設定の不備を検出 この検証で最も価値があったのがここです。 **DNS設定時にsecurity-auditorエージェントが14項目の監査レポートを生成し、次の問題を検出しました。** - **MXレコード不足（5つ中1つしか検出されていなかった）** — CRITICAL - **DMARC未設定**（なりすまし対策なしの状態） — HIGH - SPFの重複リスク - HTMLエスケープ未実装の指摘 — MEDIUM 特にMXレコード不足は深刻です。**Cloudflareの自動DNSスキャンは、5つあるはずのGoogle WorkspaceのMXレコードを1つしか拾いませんでした。**気づかずにネームサーバーを切り替えていれば、メールが止まっていた可能性があります。 **自動スキャンを信用してはいけない**——これがこの検証で得られた最も実用的な教訓です。 ## Google Workspaceを壊さずにCloudflareへ移す DNS移行で守るべきものは、メールです。移行時に必要だったMXレコードは次の5つです。 | Type | Name | Content | Priority | | --- | --- | --- | --- | | MX | @ | ASPMX.L.GOOGLE.COM | 1 | | MX | @ | ALT1.ASPMX.L.GOOGLE.COM | 5 | | MX | @ | ALT2.ASPMX.L.GOOGLE.COM | 5 | | MX | @ | ALT3.ASPMX.L.GOOGLE.COM | 10 | | MX | @ | ALT4.ASPMX.L.GOOGLE.COM | 10 | あわせてSPF（`v=spf1 include:_spf.google.com ~all`）とDKIM、そして自動スキャンでは検出されないDMARC（`v=DMARC1; p=quarantine; rua=mailto:...`）を手動で追加しました。 **DMARCは初期運用では p=none（監視のみ）で始め、問題なければ段階的に p=quarantine → p=reject へ強化するのが安全です。** ## 移行手順で押さえるべき順番 最も重要なのは順番です。 **ネームサーバーを切り替える前に、Cloudflare側のレコードを完璧にしておくこと。**切り替えた後にレコード不足が判明すると、その時点でメールが止まります。 ネームサーバー切り替え前の確認観点は次のとおりです。 1. MXレコードが5つ全て揃っているか（表示が切れている場合はクリックしてフル値を確認） 2. SPFレコードがルートドメインに1つだけか（複数あるとエラー） 3. DKIMの値がGoogle Workspace管理画面と一致するか 4. メール送信サービス側のDNSレコードが全て「Verified」か 5. DMARCが追加されているか ## ハマったポイント | エラー | 原因 | 対処法 | | --- | --- | --- | | `npm error EACCES: permission denied` | npmキャッシュにroot所有ファイルが混在 | `sudo chown -R $(whoami) ~/.npm` | | `Cannot find name '__dirname'` | vitest.config.tsをastro checkが型チェック対象にする | tsconfig.jsonのexcludeに`vitest.config.ts`を追加 | | `Cannot find module 'node:path'` | 同上 | `fileURLToPath(new URL("./src", import.meta.url))` を使う | | Cloudflare Pages「ドメインは既に使われています」 | 既存のA/CNAMEレコードが残っている | DNS設定で既存レコードを削除してからAdd | | PageSpeed Insights API 429 | レート制限 | Chrome DevToolsのLighthouseタブで手動計測 | もうひとつ、Squarespace Domainsでのネームサーバー変更にも詰まりました。**変更画面に既存ネームサーバーの「削除ボタン」がなく、「カスタム ネームサーバーを使用」ボタンをクリックすると入力フォームに切り替わる仕様**です。直感的ではないため、事前に知っておくと迷いません。 ## AIに任せられない領域 この検証では、Claude Codeが直接扱えない領域も明確になりました。 - **OS権限が絡む操作** — npmキャッシュの権限問題は `sudo` が必要で、手動介入が必要（セキュリティ的には正しい挙動） - **Cloudflare / ドメイン管理サービスのGUI操作** — 直接実行はできず、スクリーンショットベースの案内にとどまる ただし後者については、**ステップバイステップの案内が正確で、スクリーンショットを共有しながら進められました。**「代わりに操作する」ことはできなくても、「正しく案内する」ことはできるという整理になります。 ## 出力品質 | 項目 | 結果 | | --- | --- | | Lighthouse Performance | **100/100**（モバイル計測） | | Lighthouse Accessibility | **95/100** | | Lighthouse Best Practices | **100/100** | | Lighthouse SEO | **100/100** | | ビルド時間 | 約1.5秒（astro build） | | テスト実行時間 | 約7秒（13テスト・vitest run） | **Astro 6 + @astrojs/cloudflare の組み合わせでLighthouse全項目90点以上が容易に達成できる**ことも確認できました。ゼロJSをデフォルトとし、インタラクション部分のみReact Islandsにする設計です。 ## ランニングコスト | サービス | プラン | 月額 | | --- | --- | --- | | Cloudflare Pages | Free | 0円 | | Cloudflare DNS | Free | 0円 | | SSL証明書 | Cloudflare自動発行 | 0円 | | GA4 + Microsoft Clarity | 無料 | 0円 | | **合計（ホスティング部分）** | | **0円** | ## よくある質問 ### Claude Codeで開発のどこまでを任せられますか？ **プランニング、イシュー作成、TDD実装、PR作成・マージ、デプロイ設定までを一気通貫で実行できます。**OS権限が絡む操作と外部サービスのGUI操作は手動介入が必要ですが、後者は正確な手順案内が可能です。 ### どのくらい速くなりますか？ **この検証では手動開発比で約60〜70%削減と試算しています。**手動なら2〜3日かかる作業量を約3時間で完了しました。Issue 1件あたりは5〜10分でTDD実装〜PRマージまで到達しています。 ### DNS移行で最も注意すべき点は？ **ネームサーバーを切り替える前に、Cloudflare側のレコードを完璧にしておくことです。**特にMXレコードは自動スキャンが全て拾わないことがあるため、5つ全て手動で確認してください。切り替え後にレコード不足が判明するとメールが止まります。 ### セキュリティ監査エージェントは何を見つけましたか？ **14項目の監査レポートを生成し、MXレコード不足（CRITICAL）、DMARC未設定（HIGH）、SPFの重複リスク、HTMLエスケープ未実装（MEDIUM）などを検出しました。**コードレビューだけでなくDNS設定の監査にも使えることが確認できました。 ## まとめ - Claude Codeで**プランニング → Issue → TDD実装 → PR → デプロイ → DNS設定を約3時間で完了**（手動なら2〜3日相当） - **Issue 1件あたり5〜10分**でPRマージまで到達。5件を約30分で処理 - **プランモードが「設計 → 確認 → 実装」を強制するため手戻りが少ない** - **security-auditorエージェントがMXレコード不足とDMARC未設定を事前検出。**Cloudflareの自動DNSスキャンは信用しない - 成果物は**Lighthouse Performance 100 / Accessibility 95 / Best Practices 100 / SEO 100**、ホスティング費用0円 - OS権限操作と外部サービスのGUI操作は**手動介入が必要**。ただし手順案内は正確 AI駆動開発の価値は、コードを書く速度より「工程をまたぐときに止まらないこと」にあります。イシュー管理やデプロイまで同じ場所で扱えると、その効果がはっきり出ます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 電子書籍からの情報抽出はどこまで可能か｜プラットフォーム別の可否を検証 - URL: https://ai-katsu.jp/articles/kindle-shoeisha-ebook-scraping - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-02-01T00:00:00+00:00 - Models: Claude Code - Tasks: リサーチ・データ収集, ツール検証 > 電子書籍内の情報をナレッジベースへ取り込むため、AppleScript＋シェルスクリプト＋Claude Codeで抽出自動化を検証しました。翔泳社サイトは成功、Kindleブラウザ版は高度な保護により取得不可。自動化の可否が手法ではなく相手側の実装で決まることを記録しています。 社内のナレッジベースを充実させようとすると、書籍の内容をどう取り込むかが課題になります。紙の本ならスキャンですが、電子書籍は形式もプラットフォームもばらばらです。 この検証では、**AppleScript＋シェルスクリプト＋Claude Code**で電子書籍からの情報抽出を試しました。結果は**プラットフォームによって明確に分かれました。** ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年2月（2/1〜2/4） | | 技術スタック | AppleScript / シェルスクリプト / Claude Code | | やりたかったこと | 電子書籍内の情報をナレッジベースに取り込むための抽出自動化の検討 | | 結果 | **翔泳社サイトは成功／Kindleブラウザ版は高度な保護により取得不可** | | 判定 | **条件付きで導入可**（対象プラットフォームによる） | > 本記事は自社での技術検証の記録です。実施にあたっては、対象サービスの利用規約および著作権法の範囲内で行う必要があります。 ## 結論：保護の強さはプラットフォームごとに大きく違う 同じ手法を2つのプラットフォームに試した結果がこれです。 | 対象 | 結果 | | --- | --- | | 翔泳社サイト | **成功** | | Kindleブラウザ版 | **高度な保護により取得不可** | **技術的にできるかどうかは、手法ではなく相手側の実装で決まります。**同じスクリプトでも、コンテンツ保護の実装が強い側では通りません。 自動化の可否を検討するとき、**「やり方を工夫すればできる」と考えがちですが、そもそも通らない領域があります。**この見極めは早い段階で行うほうが無駄がありません。 ## AppleScript＋シェルスクリプトという構成 実装は**AppleScriptとシェルスクリプトを組み合わせ、Claude Codeで実装**する形をとりました。 Webスクレイピングというと専用ライブラリを思い浮かべますが、**画面上の操作を伴う処理ではOS側の自動化機能が有効な場合があります。**AppleScriptはmacOSのアプリケーション操作を扱えるため、ブラウザ操作を含む処理と相性があります。 ただし今回の結果が示すとおり、**この構成でも保護が強いプラットフォームは突破できません。**手段を変えれば解決するという性質の問題ではありませんでした。 ## 「できない」を記録する価値 この検証は、片方が失敗に終わっています。しかし記録としては十分な価値があります。 - 同じ課題を検討する際に、**再度同じ試行をしなくて済む** - ナレッジベース構築の設計時に、**対象を現実的な範囲に絞れる** - 「なぜその方法を採らなかったか」の根拠が残る **検証ログは成功だけを残すものではありません。**不可だった記録は、次に同じ判断をする人の時間を節約します。 ## よくある質問 ### なぜ電子書籍から情報を抽出したかったのですか？ **電子書籍内の情報をナレッジベースに取り込むためです。**抽出を自動化できれば、社内で参照できる形に整理しやすくなります。 ### どのプラットフォームで成功しましたか？ **翔泳社サイトでは成功しました。**一方、Kindleブラウザ版は高度な保護により取得できませんでした。 ### Kindleが取得できない理由は何ですか？ **プラットフォーム側の高度なコンテンツ保護によるものです。**手法を変えれば解決するという性質の問題ではありませんでした。 ## まとめ - AppleScript＋シェルスクリプト＋Claude Codeで、電子書籍からの情報抽出自動化を検証 - **翔泳社サイトは成功、Kindleブラウザ版は高度な保護により取得不可** - 自動化の可否は**手法ではなく相手側の実装で決まる**。早い段階での見極めが有効 - **不可だった記録も検証ログとして価値がある**。同じ試行の重複を防げる 自動化を検討する際は、技術的な実現可能性を先に確認しておくと計画が立てやすくなります。あわせて、対象サービスの利用規約と著作権法の範囲内で行うことが前提になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のナレッジ管理とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## MINIMAX APIで音声を一括生成｜動画1本分のナレーションを数秒で用意する - URL: https://ai-katsu.jp/articles/minimax-voice-clone-batch - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-01-20T00:00:00+00:00 - Models: Claude Code - Tools: MiniMax - Tasks: 音声・翻訳・文字起こし, ツール検証 > MINIMAX APIの音声クローン機能（T2A）を使い、複数のテキスト台本を一括で音声ファイルに変換するPython基盤を構築しました。動画1本分（数十カット）を数秒で用意できる環境、speed/pitch等による抑揚制御、そして本番量産に向けた組織用APIキーの管理課題までをまとめています。 動画やSNS投稿でキャラクターの声を使うとき、ブラウザ上のGUIツールで1つずつ生成していては量産できません。台本を直すたびに、また最初から生成し直しになります。 この検証では、**MINIMAX APIの音声クローン機能（T2A: Text to Audio）**を使い、複数のテキスト台本を一括で音声ファイルに変換する基盤を構築しました。**動画1本分（数十カット）の音声を数秒で用意できる環境**ができています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年1月〜2月（1/20〜2/4） | | 対象 | MINIMAX API（音声クローン / T2A: Text to Audio） | | 技術スタック | MINIMAX API / Python / Claude Code | | やりたかったこと | 台本の修正に伴う音声の即時・大量生成、およびAPI経由での「声の高さ・抑揚」の自動制御による人間味のあるナレーションの実現 | | 成果 | テキストファイルを読み込み、API経由で一括して音声ファイル（MP3/WAV）を指定ディレクトリへ出力する基盤を構築。**動画1本分（数十カット）の音声を数秒で用意できる環境を確立** | | 判定 | **即座に導入推奨**（プロトタイプ実装完了・量産体制移行中） | ## 結論：日本語のイントネーションが強く、レスポンスが速い この検証で確認できた優位性はこれです。 **MINIMAX APIは他社の音声合成と比較しても日本語の自然なイントネーションに強く、かつAPIのレスポンスが高速であるため、大量生成に向いています。** 音声合成ツールを選ぶとき、品質だけを見ると判断を誤ります。**量産を前提にするなら、1本あたりの生成速度が実用性を決めます。**品質が高くても遅ければ、数十カット分の音声を用意するのに時間がかかります。 この2つが両立している点が、大量生成の用途に適していると判断した理由です。 ## ブラウザ操作をなくす この検証の出発点は、**ブラウザ上のGUIツールで1つずつ生成する作業工数が膨大になる**という問題でした。 | | ブラウザGUI | API経由の一括生成 | | --- | --- | --- | | 1カットずつの操作 | 必要 | 不要 | | 動画1本分（数十カット） | 相応の時間 | **数秒** | | 台本修正後の再生成 | また1つずつ | スクリプトを再実行するだけ | 特に効くのは**台本修正後の再生成**です。制作物は必ず修正が入ります。**やり直しのコストが低いほど、修正をためらわなくなります。** 実装は、テキストファイルを読み込み、API経由で一括して音声ファイルを指定ディレクトリへ出力するPythonスクリプトです。 ## 抑揚と「間」の制御 合成音声が機械的に聞こえるのは、多くの場合抑揚と間（ポーズ）の問題です。 **感情表現やポーズ（間）の入れ方は、APIパラメータ（speed, pitch等）や特定のタグ挿入で制御可能です。** API経由であれば、この制御もスクリプト側に持てます。**「どの箇所で間を置くか」を台本の側に書いておけば、生成のたびに手で調整する必要がなくなります。** ## クローンの再現性 特定の人物の音声素材を用いたクローニング精度も確認しています。 **クローン音声の「キャラクターの再現性」は、レビューを通過できるレベルに達しました。**キャラクターの声を一貫して使い続ける用途では、この再現性が前提条件になります。 ## 課題：組織用APIキーの管理体制 技術面ではなく運用面での課題が残っています。 **API利用のための組織用APIキーの発行・管理体制**です。現時点では個別の検証用キーで対応していますが、**本番量産に向けてCSアカウントでの一元管理および請求管理への統合を申請中**です。 APIを使った仕組みは、検証段階では個人のキーで動きます。しかし本番運用に移すときには、**誰がキーを持ち、費用をどこで見るのかを決めておかないと運用が破綻します。**技術検証が終わった後に必ず出てくる論点です。 ## 次の展開：台本から動画までの全自動化 追加で検証したい項目として、次を挙げています。 - **Remotion（動画生成エンジン）とのAPI連携により、「台本入力 → 音声生成 → 動画合成」を全自動で行うパイプラインの構築** - **ユーザーの反応（聞き取りやすさ等）をフィードバックし、最適な「声のトーン」をAIが自動選択する学習機能の検討** 音声だけ自動化しても、動画に組み込む工程が手作業なら全体の時間は大きく変わりません。**つなげて初めて効果が出る**という構造です。 ## よくある質問 ### MINIMAX APIの強みは何ですか？ **日本語の自然なイントネーションに強く、APIのレスポンスが高速な点です。**他社の音声合成と比較しても、この2つが両立しているため大量生成に向いています。 ### どのくらい速く生成できますか？ **動画1本分（数十カット）の音声を数秒で用意できます。**ブラウザ操作を介さないため、台本修正後の再生成もスクリプトの再実行だけで済みます。 ### 抑揚や「間」は調整できますか？ **APIパラメータ（speed, pitch等）や特定のタグ挿入で制御可能です。**制御をスクリプト側に持てるため、生成のたびに手で調整する必要がありません。 ### 導入時の注意点はありますか？ **組織用APIキーの発行・管理体制です。**検証段階は個別のキーで動きますが、本番量産では一元管理と請求管理への統合が必要になります。 ## まとめ - MINIMAX APIの音声クローン（T2A）で、**複数台本を一括して音声ファイル出力する基盤**をPythonで構築 - **動画1本分（数十カット）の音声を数秒で用意できる環境**を確立。台本修正後の再生成も容易 - 優位性は**日本語イントネーションの自然さとAPIレスポンスの速さの両立** - **抑揚・ポーズはspeed / pitch等のパラメータやタグ挿入で制御可能** - 残る課題は**組織用APIキーの発行・管理体制**。一元管理と請求統合を申請中 - 次はRemotionと連携し**「台本入力 → 音声生成 → 動画合成」の全自動パイプライン**へ 音声合成の選定では、出力品質と同じくらい「量産できるか」が判断材料になります。API経由で回せる構成にしておくと、修正のコストが下がり、制作全体の回転が速くなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のコンテンツ制作へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 動画媒体の指標はAPIで取れるか｜TikTok・Instagram Graph APIの仕様再整理 - URL: https://ai-katsu.jp/articles/sns-api-tiktok-instagram - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-01-20T00:00:00+00:00 - Tools: TikTok, Instagram - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: マーケティング > TikTok（Display API等）とInstagram Graph APIの仕様とインサイト取得方法を再整理しました。再生数・保存数・シェア数といった動画特有の指標を自動集計できるかの見極めが焦点です。指標がAPIで取れないと、投稿を自動化しても効果測定が手作業で残ります。 SNS運用の効果測定は、テキスト中心の媒体と動画媒体で見るべき指標が変わります。動画媒体への進出を検討する段階で必要になるのが、**「その指標をAPIで自動集計できるか」の確認**です。 この検証では、**TikTok APIとInstagram Graph APIの仕様とインサイト取得方法を再整理**しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年1月〜2月（1/20〜2/4） | | 対象 | TikTok API（Display API等）／Instagram Graph API | | やりたかったこと | 動画媒体（TikTok、Instagram Reels）への進出に備え、各プラットフォームのAPI仕様とインサイト取得方法を再整理する | | 実施したこと | 過去の調査結果（Instagram Graph API等）の掘り起こしと、**TikTok API（Display API等）の最新ドキュメントの確認** | | 焦点 | **ショート動画の再生数、保存数、シェア数などの「動画特有の指標」を自動集計できるかの見極め** | | 状況 | 調査再開フェーズ | > 本記事は自社での検証記録です。実装・運用には至っていないため、成果の数値はありません。 ## 結論：動画媒体は「見る指標」が違う この調査の焦点はここに絞られます。 **ショート動画の再生数、保存数、シェア数などの「動画特有の指標」を自動集計できるかの見極め**です。 テキスト中心の媒体では、インプレッションやいいね、リンククリックが主な指標になります。しかし**動画媒体では「保存」と「シェア」の重みが変わります。**後で見返すために保存された、他人に共有された——この2つは、単純な再生数より内容の評価を反映します。 そして重要なのは、**これらの指標がAPIで取得できるかどうかは媒体ごとに異なる**という点です。管理画面では見えても、APIで降りてこない指標があります。 ## なぜ「取得できるか」を先に見るのか 運用を自動化する前提で媒体を選ぶなら、**指標が自動で集まるかどうかは設計に直結します。** | 状況 | 結果 | | --- | --- | | APIで取得できる | 集計・分析まで自動化できる | | 管理画面にしかない | 毎回手作業で転記が発生する | 後者になると、**投稿は自動化できても効果測定が手作業**という状態になります。運用を始めてから気づくと、媒体を増やすほど手間が増えます。 **進出を決める前に確認しておく**——この順番が調査の目的です。 ## 過去の調査を掘り起こす この調査では、**過去の調査結果（Instagram Graph API等）の掘り起こし**から始めています。 API仕様の調査は一度やって終わりにはなりません。しかし**ゼロからやり直す必要もありません。**過去に調べた内容を出発点にして、変更点だけを最新ドキュメントで確認するほうが早く済みます。 TikTok API（Display API等）については、最新ドキュメントを確認しました。 調査記録を残しておくと、**再開時のコストが下がります。**API仕様は変わりますが、変わった箇所を見るには前回の内容が必要です。 ## よくある質問 ### なぜAPI調査から始めるのですか？ **指標が自動で取得できるかが、運用設計に直結するためです。**管理画面にしかない指標だと、投稿を自動化しても効果測定が手作業のまま残ります。 ### 動画媒体で重要な指標は何ですか？ **再生数、保存数、シェア数などの「動画特有の指標」です。**特に保存とシェアは、単純な再生数より内容の評価を反映します。 ### 過去の調査は使えますか？ **出発点として使えます。**API仕様は変わりますが、変更点だけを最新ドキュメントで確認するほうが、ゼロからやり直すより早く済みます。 ## まとめ - 動画媒体（TikTok、Instagram Reels）進出に備え、**TikTok APIとInstagram Graph APIの仕様・インサイト取得方法を再整理** - 焦点は**再生数・保存数・シェア数など「動画特有の指標」を自動集計できるかの見極め** - 指標がAPIで取れないと、**投稿は自動化できても効果測定が手作業で残る** - 過去の調査結果を掘り起こし、**変更点だけを最新ドキュメントで確認する**進め方 媒体を増やす判断は、届く範囲だけでなく「測れるか」で決まります。自動化を前提にするなら、API仕様の確認は進出前に済ませておくのが確実です。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 課題評価をAIで自動化する｜GAS＋スプレッドシートで基準の揺れをなくす設計 - URL: https://ai-katsu.jp/articles/skill-test-auto-evaluation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-01-15T00:00:00+00:00 - Tools: Google Apps Script, Google Workspace - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: 採用・人事 > 受講生が提出する課題の評価を一貫した基準でAIが行う仕組みを、GASとスプレッドシートで構築しています。評価エンジンの「たたき」を作る前に管理用スプレッドシートの項目を根本から見直した理由と、既存の運用環境の上に載せる設計判断をまとめています。 受講生が提出する課題の評価は、担当者ごとに基準がぶれやすい業務です。同じ提出物でも、見る人が変われば評価が変わる。この揺れは、受け取る側の納得感に直結します。 この検証では、**GASとスプレッドシートで課題評価を自動化する仕組み**を構築しています。ただし、最初に手をつけたのは評価エンジンではありませんでした。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年1月〜2月（1/15〜2/4） | | 使用ツール | GAS（Google Apps Script）／スプレッドシート | | やりたかったこと | **受講生が提出する課題の評価を一貫した基準でAIが行い、管理工数を削減しつつフィードバックの質を担保する** | | 実施したこと | GASによる評価エンジンの「たたき」作成／**管理用スプレッドシートの項目の根本的な見直し** | | 状況 | レビュー・修正フェーズ（実運用に向けた最終調整中） | > 本記事は自社での検証記録です。評価工数の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：評価エンジンより先に、管理項目を見直した この検証で実施したことは2つです。 - **GASによる評価エンジンの「たたき」作成** - **管理用スプレッドシートの項目の根本的な見直し** 注目すべきは後者です。**評価を自動化するには、評価結果を入れる器のほうを先に整える必要があります。** AIに評価させるとき、出力は必ずどこかに記録されます。その記録先の項目設計が曖昧だと、**「評価はできたが、後から使えないデータが溜まる」**という状態になります。項目を根本から見直したのは、そのためです。 自動化の話をすると仕組みの側に目が行きますが、**実際にボトルネックになるのはデータの受け皿**であることが少なくありません。 ## なぜ評価をAIに任せるのか 目的は2つあります。 | 目的 | 内容 | | --- | --- | | **基準の一貫性** | 同じ基準で評価されるため、評価者による揺れが起きない | | **管理工数の削減** | 提出物を1件ずつ人が確認する作業を減らす | この2つは、どちらか一方だけでは意味がありません。**工数だけ減らして評価の質が落ちれば、受講生にとっての価値が下がります。**だからこそ「フィードバックの質を担保しつつ」という条件がついています。 ## GASとスプレッドシートを選んだ意味 構成はGASとスプレッドシートです。専用のシステムを作るのではなく、**すでに運用に使っているスプレッドシートの上に評価の仕組みを載せる**形になります。 - 提出物の管理はすでにスプレッドシートで行われている - GASなら同じ環境の中で処理を完結できる - 評価結果もそのままシートに書き戻せる **既存の運用場所から動かさないことは、定着のしやすさに直結します。**新しいツールを導入すると、そこを見に行く習慣づくりから始めることになります。 ## 「たたき」で止めて確認プロセスに入る 現在は**レビュー・修正フェーズ**です。評価エンジンは「たたき」の段階で確認プロセスに回し、実運用に向けた最終調整を進めています。 評価の仕組みは、**作り込んでから見せると直しにくくなります。**評価基準そのものへの合意が必要な領域では、早い段階で叩き台を出して基準をすり合わせるほうが、結果的に手戻りが少なくなります。 ## よくある質問 ### なぜ課題評価をAIに任せるのですか？ **一貫した基準で評価するためと、管理工数を削減するためです。**評価者によって基準が揺れる問題を避けつつ、フィードバックの質を担保することが目的です。 ### なぜスプレッドシートの項目を見直したのですか？ **評価結果を記録する器の設計が曖昧だと、後から使えないデータが溜まるためです。**評価エンジンを作る前に、管理用スプレッドシートの項目を根本から見直しました。 ### なぜGASなのですか？ **提出物の管理がすでにスプレッドシートで行われているためです。**同じ環境の中で処理を完結でき、評価結果もそのまま書き戻せます。既存の運用場所から動かさないことは定着のしやすさに直結します。 ## まとめ - 受講生の課題評価を**GAS＋スプレッドシートで自動化**する仕組みを構築中 - 目的は**基準の一貫性と管理工数の削減の両立**。片方だけでは意味がない - 評価エンジンより先に**管理用スプレッドシートの項目を根本から見直した**。自動化のボトルネックはデータの受け皿にある - 評価基準の合意が必要な領域では、**「たたき」の段階で確認プロセスに回す**ほうが手戻りが少ない 評価の自動化は、判定ロジックだけの問題ではありません。どんな項目で記録するかを決めた時点で、その後に何ができるかが決まります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## チャットAIの「3秒ルール」を回避する｜非同期キューで組む汎用エージェント基盤の設計 - URL: https://ai-katsu.jp/articles/async-agent-platform-design - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-01-10T00:00:00+00:00 - Tools: Slack, Discord - Tasks: AIエージェント, 業務プロジェクト - Domain: 社内基盤・インフラ > Discordで動いていたAIエージェントをSlack・Teams・Chatworkへ横展開するため、「表玄関（受付）→ QStash（非同期キュー）→ 裏口（実行）」の3層アーキテクチャを設計しました。プラットフォームごとのタイムアウト制約への対処と、LangGraphのthread_idによるマルチユーザー混線防止設計をまとめています。 Discordで動いていたAIエージェントを、Slack・Teams・Chatworkへ横展開する。一見すると「接続先を増やすだけ」に見えますが、実際にはプラットフォームごとに**タイムアウトの制約と認証方式が違います。** この違いを吸収する共通基盤として、**「表玄関（受付）→ 非同期キュー → 裏口（実行）」というアーキテクチャ**を設計しました。同時に複数人が会話しても混線しない仕組みも標準化しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年1月〜2月（1/10〜2/4） | | 使用ツール | QStash / LangGraph / Slack（HTTPモード）/ Teams（Azure Bot Service） | | やりたかったこと | Discordで動いていたエージェント機能を、Slack・Teams・Chatworkへ低コストで横展開する | | 設計 | **「表玄関（受付）→ QStash（非同期キュー）→ 裏口（実行）」**という3層アーキテクチャ | | 混線対策 | **LangGraphの `thread_id` を用いたマルチユーザー混線防止設計** | | 状況 | 設計完了・一部実装中（Slack先行） | > 本記事は自社での検証記録です。実運用に至っていないため、効果の数値はありません。 ## 結論：3秒ルールが設計を決める チャットツールにAIエージェントを組み込む際、最初に突き当たるのがこれです。 **プラットフォームごとに「3秒ルール（タイムアウト）」があります。**受け取ったイベントに対して、決められた時間内に応答を返さないとエラー扱いになります。 しかしAIの処理は数秒では終わりません。**考えている間にタイムアウトする**という構造的な問題が発生します。 ### 解決策：受付と実行を分離する ``` 表玄関（受付） チャットツールからのイベントを受け取り、即座に「受け付けた」と返す ↓ QStash（非同期キュー） 処理の依頼を溜める ↓ 裏口（実行） 時間をかけてAIが処理し、結果を後から投稿する ``` **「すぐ返す」と「時間をかけて処理する」を分けることで、タイムアウトの制約を回避します。**受付だけなら3秒で終わります。 この構造は、チャットツールに限らず**応答時間の制約がある連携全般で使えます。** ## 複数人が同時に話しても混線しない設計 もうひとつの重要な論点がこれです。 チャットツールは複数人が同時に使います。AさんとBさんが同時にエージェントへ話しかけたとき、**会話の文脈が混ざらないようにする必要があります。** 対応として、**LangGraphの `thread_id` を用いたマルチユーザー混線防止設計**を採用しました。**2人以上が同時に会話しても混線しない「ID正規化ロジック」を標準化しています。** ## 共通基盤にするための正規化 プラットフォームごとに、ユーザーやチャンネルの識別方法は異なります。これをそのまま扱うと、接続先ごとに別の実装が必要になります。 **すべてのチャットツールからの入力を `thread_id` として正規化し、バックエンドを共通化する**という判断をしました。理由はメンテナンス性です。 | アプローチ | 結果 | | --- | --- | | プラットフォームごとに実装 | 接続先が増えるほど保守が重くなる | | **入口で正規化して共通化** | **バックエンドは1つで済む** | **違いは入口で吸収し、中は共通にする。**横展開を前提にするなら、この設計が効いてきます。 ## 検証の進捗 - **Slack（HTTPモード）でのイベント受信とQStash連携の検証完了** - **Teams（Azure Bot Service経由）の実現可能性確認** Slackを先行して実装を進めています。認証方式がプラットフォームごとに違うため、**1つずつ確認しながら共通化の範囲を見極める**進め方です。 ## よくある質問 ### 3秒ルールとは何ですか？ **チャットツールが定めるイベント応答のタイムアウト制約です。**決められた時間内に応答を返さないとエラー扱いになります。AIの処理は数秒では終わらないため、受付と実行を分離する必要があります。 ### なぜ非同期キューを挟むのですか？ **「すぐ返す」と「時間をかけて処理する」を分離するためです。**表玄関でイベントを受け取って即座に応答し、実際の処理はキュー経由で裏口が担当します。 ### 複数人が同時に使っても大丈夫ですか？ **LangGraphの `thread_id` によるID正規化ロジックで混線を防いでいます。**2人以上が同時に会話しても、文脈が混ざらない設計です。 ### なぜ入力を正規化するのですか？ **バックエンドを共通化してメンテナンス性を保つためです。**プラットフォームごとに実装を分けると、接続先が増えるほど保守が重くなります。違いは入口で吸収します。 ## まとめ - チャットツール連携では**「3秒ルール（タイムアウト）」が設計を決める** - 対応は**「表玄関（受付）→ 非同期キュー → 裏口（実行）」の3層構造**。すぐ返す処理と時間のかかる処理を分離する - 複数人の同時利用には**LangGraphの `thread_id` によるID正規化**で混線を防止 - 横展開を前提にするなら**違いは入口で吸収し、バックエンドは共通化する** 複数のプラットフォームに展開する仕組みでは、個別対応を積み上げるほど保守が重くなります。どこで差異を吸収するかを最初に決めておくと、後から増やすのが楽になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAI基盤づくりを支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## コードで動画を作る｜Remotionで解説動画を量産する仕組みと「何を作るか」の基準値 - URL: https://ai-katsu.jp/articles/remotion-video-engine - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2026-01-10T00:00:00+00:00 - Tools: Remotion, MiniMax - Tasks: 資料作成・デザイン, 業務プロジェクト > プログラミングで動画を生成できるRemotionを使い、テロップ・背景等の基本コンポーネントと30秒〜3分の解説用テンプレートを構築しました。あわせて動画の「レッスン化（教材化）」の基準値を策定し、どの情報を動画にするかを数値で判断できる状態にしています。MINIMAX APIによるクローン音声の合成も検証中です。 AIツールの解説動画は、作った翌月には古くなります。だからこそ量産できる体制が必要ですが、動画編集は工数のかかる作業です。 この検証では、**プログラミングで動画を生成できる「Remotion」**を使い、解説動画のテンプレートを構築しました。あわせて、**どの情報を動画にするかの基準**も策定しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年1月〜2月（1/10〜2/4） | | 使用ツール | Remotion / MINIMAX API | | やりたかったこと | 動画編集の工数削減と、最新情報を即座にショート動画化する体制の構築 | | 作ったもの | テロップ・背景・フォント等の基本コンポーネント／**30秒〜3分程度の解説用テンプレート** | | あわせて策定 | **動画の「レッスン化（教材化）」の基準値**——どの情報を動画にするかの選別が可能に | | 状況 | プロトタイプ完成・調整フェーズ | > 本記事は自社での検証記録です。制作時間の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：作る仕組みより「何を作るか」の基準が要る この検証で最も重要だったのは、技術より運用側の整理でした。 **動画の「レッスン化（教材化）」の基準値を策定し、どの情報を動画にするかの選別が可能になりました。** 量産できる仕組みを作ると、次に「何を作るか」で止まります。AI領域は情報量が多く、**すべてを動画にすることはできません。**選別の基準がないと、結局は人が毎回悩むことになります。 そこで**教材更新の基準（注目度・コミュニティでの反応数）を言語化・指標化しました。**数値で判断できる状態にすることで、「これは動画にする」の決定が速くなります。 **生成の自動化と、選別の自動化は別問題です。**両方揃って初めて量産体制になります。 ## Remotionで作ったもの Remotionは、コードで動画を組み立てるフレームワークです。この検証では次を実装しました。 - **基本コンポーネント** — テロップ、背景、フォント等 - **解説用テンプレート** — 30秒〜3分程度の尺を想定 - **可読性の高いテロップ表示** — 薄い背景を敷く実装 テロップの背景処理は地味ですが効きます。**背景の映像によっては文字が埋もれるため、薄い背景を敷くだけで可読性が大きく変わります。**ショート動画は音声なしで見られることも多く、文字が読めるかどうかは伝達に直結します。 ## コードで動画を作る意味 | | 編集ソフト | Remotion | | --- | --- | --- | | 1本目を作る | 速い | コンポーネント作成が必要 | | 2本目以降 | 毎回同じ作業 | **テンプレートに流し込むだけ** | | 一括修正 | 1本ずつ直す | **コンポーネントを直せば全部反映** | **量産を前提にするなら、初期コストを払ってでもコードベースにする価値があります。**特に「フォントを変えたい」「レイアウトを調整したい」が全本に効く点は、手作業では得られません。 ## 音声：クローン音声の合成を検証 **MINIMAX APIを用いたクローン音声の合成も検証しています。** 解説動画にはナレーションが必要ですが、毎回録音するのは量産の妨げになります。音声も生成できれば、**テキストから動画までを一続きで自動化できます。** ## よくある質問 ### Remotionとは何ですか？ **プログラミングで動画を生成できるフレームワークです。**テロップや背景をコンポーネントとして定義し、テンプレートに流し込む形で動画を作れます。 ### 編集ソフトを使うのと何が違いますか？ **2本目以降の速さと、一括修正のしやすさです。**コンポーネントを直せば全動画に反映されます。1本だけ作るなら編集ソフトのほうが速いです。 ### どの情報を動画にするか、どう決めていますか？ **教材更新の基準（注目度・コミュニティでの反応数）を言語化・指標化しました。**数値で判断できる状態にすることで、選別が速くなります。 ### ナレーションはどうしていますか？ **MINIMAX APIを用いたクローン音声の合成を検証しています。**音声も生成できれば、テキストから動画までを一続きで自動化できます。 ## まとめ - Remotionで**テロップ・背景等の基本コンポーネントと、30秒〜3分の解説用テンプレート**を構築 - **薄い背景を敷いた可読性の高いテロップ表示**を実装。音声なしで見られる前提では文字の可読性が効く - コードベースの利点は**2本目以降の速さと、コンポーネント修正が全動画に反映されること** - **「何を動画にするか」の基準値を策定。**生成の自動化と選別の自動化は別問題 - MINIMAX APIによる**クローン音声の合成**も検証中 コンテンツの量産では、作る速度より「何を作るかを決める速度」がボトルネックになります。基準を数値化しておくと、そこで止まらなくなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のコンテンツ制作へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## n8nからNode.jsへ完全移行｜SNS自動投稿を無料枠で安定運用するリトライ設計 - URL: https://ai-katsu.jp/articles/x-techjii-engagement - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-12-20T00:00:00+00:00 - Tools: X（旧Twitter）, Vercel - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: マーケティング > X（旧Twitter）の自律運用を高度化するため、複雑な条件分岐と外部API連携の負荷を理由にn8nからNode.js基盤（Render/Vercel）へ完全移行しました。Render無料版の疎通エラーに対するリトライロジック、重複リストの割愛ロジック、エンゲージメント基準が持つ「届く範囲が固定される」弱点への対処をまとめています。 SNSの自動投稿は、動き始めてからが本番です。同じような内容が続く、特定の層にしか届かない、無料枠のホスティングが不定期に落ちる——運用して初めて見える問題が次々に出てきます。 この検証では、**n8nからNode.js基盤への完全移行**と、運用で見つかった課題への対処を進めました。特にRender無料版の疎通エラーには、**リトライロジック**で対応しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年12月〜2026年2月（12/20〜2/4） | | 使用ツール | Node.js / Render / Vercel / fal.ai | | やりたかったこと | 情報発信だけでなく交流やトレンド解析を含めた自律運用を実現し、幅広いユーザーへ接触する | | 方針 | **複雑な条件分岐と外部API連携の負荷を考慮し、n8nからNode.js基盤（Render/Vercel）へ完全移行** | | 実装したもの | 重複リストの割愛ロジック／エンゲージメント計算（上位5件抽出）／**Render無料版の疎通エラーに対するリトライロジック** | | 状況 | ロジック修正・基盤移行フェーズ | > 本記事は自社での検証記録です。インプレッションやエンゲージメントの変化などの測定は行っていないため、数値は掲載していません。 ## 結論：無料枠で回すならリトライは必須 運用で最も効いた実装がこれです。 **Render無料版の疎通エラーに対して、リトライロジックを実装しました。** 無料枠のホスティングは、一定時間アクセスがないとインスタンスが停止します。次のリクエストで起動しますが、その待ち時間でタイムアウトすることがあります。**コードは正しいのに、たまに失敗する**という状態です。 これを「無料枠だから仕方ない」で済ませると、自動投稿が静かに止まります。**リトライを入れておけば、多くの場合は2回目で通ります。**制約を前提に、失敗しても復帰する作りにするという対応です。 ## n8nからNode.jsへの完全移行 基盤の移行理由は、**複雑な条件分岐と外部API連携の負荷**です。 投稿内容の選別、重複チェック、画像の添付、エラー時の分岐——要件が積み重なるほど、ノーコードのフローは見通しが悪くなります。**条件分岐が増えた時点で、コードで書いたほうが読みやすくなります。** 移行先はRenderとVercelです。 ## 重複投稿を防ぐ 運用課題のひとつが、**重複した内容の投稿**でした。同じ話題が別のポストとして収集されると、似た投稿が続いてしまいます。 対応として**重複リストの割愛ロジックを追加**しました。エンゲージメント計算で上位5件を抽出する仕組みと組み合わせ、質と多様性の両方を担保します。 ## 接触するユーザー層を広げる もうひとつの課題が、**特定の層に偏らない幅広いユーザーへの接触**です。 エンゲージメント基準で選別すると、どうしても同じような話題・同じような層に寄ります。**反応が良いものだけを選ぶと、届く範囲が固定される**という構造的な問題です。 現在は、ターゲットとするユーザー層への接触を増やすためのアルゴリズム改修に着手しています。 ## よくある質問 ### なぜn8nから移行したのですか？ **複雑な条件分岐と外部API連携の負荷を考慮したためです。**要件が積み重なるほどノーコードのフローは見通しが悪くなります。分岐が増えた時点でコードのほうが読みやすくなります。 ### 無料枠のホスティングで運用できますか？ **リトライロジックがあれば可能です。**Render無料版はスリープ仕様により不定期に疎通エラーが発生しますが、多くの場合はリトライで通ります。制約を前提に復帰する作りにしてください。 ### 重複投稿はどう防いでいますか？ **重複リストの割愛ロジックを追加しています。**エンゲージメント計算による上位5件の抽出と組み合わせ、質と多様性を両立させています。 ### エンゲージメント基準の弱点は？ **反応が良いものだけを選ぶと、届く範囲が固定されます。**特定の層に偏りやすいため、接触するユーザー層を広げるアルゴリズム改修に着手しています。 ## まとめ - 複雑な条件分岐と外部API連携の負荷から、**n8nからNode.js基盤（Render/Vercel）へ完全移行** - **Render無料版の疎通エラーにはリトライロジックで対応。**無料枠で回すなら必須の備え - **重複リストの割愛ロジック**を追加し、似た投稿が続くのを防止 - エンゲージメント基準は**届く範囲が固定されやすい**という弱点がある。層を広げる改修に着手 自動化は作った時点では完成せず、運用で見えた問題を潰す期間が必ず必要になります。特に無料枠を使う場合は、失敗する前提の設計が効きます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## RSSの中身は提供元次第｜ツール更新の自動監視で足りなかった情報 - URL: https://ai-katsu.jp/articles/ai-info-curriculum-update - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-12-12T00:00:00+00:00 - Models: Microsoft Copilot - Tasks: ナレッジ活用・RAG, 業務プロジェクト - Domain: 教育・研修 > 教材の鮮度を保つため主要ツールのアップデートを自動監視する仕組みを構築中です。Microsoft Copilot等のリリースノートではRSSで取得できるのがサイトへのリンクのみで、具体的な更新内容が不足していました。AIに詳細リンク先をクローリングさせ変更点を要約するステップの追加を検討しています。 教材の鮮度を保つには、扱っているツールのアップデートを追い続ける必要があります。この監視を自動化する仕組みを構築し、現在はロジックの改修を進めています。 改修の理由は、**RSSから取得できる情報が想定より少なかった**ことです。提供元によって、通知に必要な情報が揃わないケースがあります。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年12月（12/12〜12/19） | | やりたかったこと | 教材の鮮度を保つため、主要ツールのアップデート情報を自動監視しDiscordへ通知する | | 発生した課題 | **Microsoft Copilot等のリリースノートでは、RSSで取得できるのが「サイトへのリンク」のみで、具体的な更新内容が不足** | | 検討中の対応 | **詳細リンク先をAIにクローリングさせ、変更点を要約するステップの追加** | | 状況 | ロジック改修中 | > 本記事は自社での検証記録です。情報収集工数の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：RSSの中身は提供元次第 この改修の発端となった問題です。 **Microsoft Copilot等のリリースノートでは、RSSで取得できるのが「サイトへのリンク」のみでした。**具体的な更新内容が含まれていません。 RSSフィードの仕様は共通でも、**どこまで中身を載せるかは提供元の判断です。**本文まで含めるところもあれば、タイトルとリンクだけのところもあります。 監視の仕組みを組むとき、この差は設計に直結します。**複数のツールを横断して監視する場合、最も情報の少ない提供元に合わせた作りが必要になります。** ## なぜリンクだけでは足りないのか この仕組みの目的は、**教材への反映が必要な変更を見つけること**です。 「更新がありました」という通知だけでは、判断できません。結局リンクを開いて内容を読むことになり、**自動化する前と作業量が変わりません。** 通知の価値は、**読んだだけで次の行動が決まること**にあります。そこに届いていなければ、通知は仕事を増やすだけです。 ## 検討している対応：AIにクローリングさせる **詳細リンク先をAIにクローリングさせ、変更点を要約するステップの追加を検討しています。** ``` RSS を監視 → 更新を検知（リンクのみ） ↓ AI が詳細リンク先をクローリング ↓ 変更点を要約 Discord へ通知（判断できる形で） ``` 取得できる情報が足りないなら、**足りない分を取りに行く工程を足す**という単純な方針です。ステップは増えますが、通知の質は保てます。 ## よくある質問 ### RSSで足りないのはなぜですか？ **どこまで中身を載せるかは提供元の判断だからです。**Microsoft Copilot等では、サイトへのリンクのみで具体的な更新内容が含まれていませんでした。 ### リンクだけの通知では何が問題ですか？ **結局リンクを開いて読むことになり、自動化前と作業量が変わりません。**通知は「読んだだけで次の行動が決まる」状態になって初めて価値が出ます。 ### どう解決する予定ですか？ **詳細リンク先をAIにクローリングさせ、変更点を要約するステップの追加を検討しています。**取得できる情報が足りないなら、取りに行く工程を足すという方針です。 ## まとめ - 教材の鮮度を保つため、主要ツールのアップデートを自動監視する仕組みを構築中 - **RSSの中身は提供元次第。**Microsoft Copilot等ではリンクのみで更新内容が不足していた - 複数ツールを横断監視する場合、**最も情報の少ない提供元に合わせた作り**が必要 - 対応は**AIによる詳細リンク先のクローリングと要約ステップの追加** 情報収集の自動化では、集めることより「判断できる形にすること」に手間がかかります。通知が届いても読み解けなければ、作業は減りません。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のナレッジ管理とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 完成しても運用しない判断｜社内タスク管理の自動通知を「仕様待ち」で止めた理由 - URL: https://ai-katsu.jp/articles/internal-task-management-prototype - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-12-12T00:00:00+00:00 - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: バックオフィス > 営業アラートシステムの技術（Render + Node.js）を転用し、社内タスク管理の自動通知プロトタイプを構築しました。デプロイすれば即時運用可能な状態ですが、社内の管理基準が変更される可能性があるため本格実装は保留に。手戻りを防ぐために待つという設計判断と、既存資産を転用する進め方をまとめています。 営業向けに作ったアラート通知システムが安定稼働していたので、**同じ技術を社内のタスク管理に転用**できないかを試しました。 プロトタイプは完成し、デプロイすれば即座に運用できる状態です。それでも**本格実装は保留**にしました。理由は技術的なものではありません。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年12月（12/12〜12/19） | | 使用ツール | Render / Node.js | | やりたかったこと | 営業アラートシステムで培った技術を転用し、社内タスク管理を自動通知化する | | 到達点 | **ローカル環境でのプロトタイプ動作を確認。Renderへデプロイすれば即時運用可能な状態** | | 判断 | **社内の管理基準が変更される可能性があるため、手戻り防止のため本格実装は保留** | | 状況 | プロトタイプ完了（仕様待ち） | > 本記事は自社での検証記録です。運用に至っていないため、工数削減などの数値はありません。 ## 結論：動くものができても、すぐに出さない判断がある この検証で記録すべきなのは、**「完成しているのに出さない」という判断**です。 プロトタイプはローカル環境で動作を確認済みで、**Renderへデプロイすれば即時運用可能な状態**にあります。技術的な障壁は残っていません。 それでも保留にしたのは、**社内の管理基準が変更される可能性があるためです。**基準が変わればタスクの区分や通知の条件も変わります。いま実装して運用に乗せると、変更のたびに作り直すことになります。 **手戻りを防ぐために、あえて待つ。**これも設計判断のひとつです。 ## 既存資産の転用という進め方 この取り組みが短期間でプロトタイプまで到達できたのは、**営業アラートシステムで培った技術（Render + Node.js）をそのまま転用したから**です。 | | 営業アラート | タスク管理 | | --- | --- | --- | | 技術構成 | Render + Node.js | 同じ | | やっていること | 条件を満たしたら通知 | 同じ | | 変わる部分 | — | 監視対象と通知条件 | **「条件を満たしたら通知する」という構造は、対象を変えても再利用できます。**一度作った仕組みを別の業務に持っていけると、2つ目以降の立ち上がりが速くなります。 自動化を進めるときは、**個別最適な仕組みを積み上げるより、転用しやすい形で作っておくほうが結果的に効率的です。** ## 「仕様待ち」で止めることの意味 保留という判断は、消極的に見えるかもしれません。しかし実務では、**仕様が固まっていない段階で作り込むほうがリスクが高い**場面があります。 - 基準が変わるたびに改修が必要になる - 使い始めてから変更すると、運用中の混乱を招く - 作り直しの手間が、削減した工数を上回ることもある **プロトタイプまで作って動くことを確認しておけば、仕様が固まった時点ですぐ動けます。**止めているのは実装であって、検証ではありません。 ## よくある質問 ### 完成しているのになぜ運用しないのですか？ **社内の管理基準が変更される可能性があるためです。**基準が変わればタスクの区分や通知条件も変わるため、いま実装すると手戻りが発生します。 ### プロトタイプはどこまでできていますか？ **ローカル環境での動作確認まで完了しており、Renderへデプロイすれば即時運用可能な状態です。**技術的な障壁は残っていません。 ### なぜ短期間で作れたのですか？ **営業アラートシステムで培った技術（Render + Node.js）を転用したためです。**「条件を満たしたら通知する」という構造は、対象を変えても再利用できます。 ## まとめ - 営業アラートの技術を転用し、**社内タスク管理の自動通知プロトタイプが完成** - デプロイすれば即時運用可能だが、**管理基準が変わる可能性があるため本格実装は保留** - **手戻りを防ぐために待つ**のも設計判断のひとつ - **「条件を満たしたら通知する」構造は対象を変えて再利用できる**。転用しやすい形で作っておくと2つ目以降が速い 自動化は作れば作るほど良いわけではありません。仕様が動く可能性があるなら、プロトタイプで止めておくほうが結果的に無駄が少なくなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 踏み台MCPサーバで「誰でも使える」を作る｜難所はホスティングではなく秘匿情報の管理 - URL: https://ai-katsu.jp/articles/remote-mcp-bastion - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-22T00:00:00+00:00 - Tools: MCP, Google Apps Script - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: 社内基盤・インフラ > GA4やClarityのデータをAIチャットから扱える環境を、個々のローカル環境に依存しない形へ移行しました。踏み台MCPサーバを経由してGAS MCPサーバへ接続し、アクセストークンの管理を集約する構成です。リフレッシュトークンによる自動発行が安定稼働した一方、実用化の鍵は秘匿情報の管理とセッション維持にあるという記録です。 AIチャットからGA4やClarityのデータを直接扱えるようにする。この体験は便利ですが、ローカルMCPで組むと**構築した本人しか使えません。** 誰でも簡単に使える環境にするため、**踏み台MCPサーバを経由する構成**を設計しました。実装を進める中で、実用化の鍵は機能ではなく**秘匿情報の管理とセッション維持**にあることがはっきりしました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月〜12月（11/22〜12/19） | | 使用ツール | MCP / GAS | | やりたかったこと | 個々のローカル環境に依存せず、誰でも簡単にGA4やClarityのデータをAIチャット上で扱えるようにする | | 構成案 | **踏み台MCPサーバ → GAS MCPサーバ（アクセストークン管理）** | | 達成できたこと | **リフレッシュトークンを用いたアクセストークンの自動発行（プロンプトベース）が安定稼働** | | 実用化の鍵 | リモートホスティング時の**秘匿情報（キー）の管理とセッション維持の設計** | | 状況 | アーキテクチャ構築フェーズ | > 本記事は自社での検証記録です。工数削減などの定量測定は行っていないため、数値は掲載していません。 ## 結論：ホスティングは簡単、秘匿情報の管理が難しい この構築で明確になった論点です。 **リモートホスティング（Vercel / Render等）を行う際、秘匿情報（キー）の管理とセッション維持の設計が実用化の鍵となります。** MCPサーバをクラウドに載せること自体は、それほど難しくありません。詰まるのはその先です。 - **キーをどこに置くか** — 環境変数に入れるとして、誰が更新するのか - **セッションをどう維持するか** — 複数の利用者が同時に使う場合の扱い - **トークンをどう更新し続けるか** — 期限切れで止まらないようにする **ローカルで動いていたときには存在しなかった問題が、共有した瞬間にまとめて現れます。** ## 構成：踏み台を挟んでトークン管理を集約する ``` クライアント（AIチャット） ↓ 踏み台 MCP サーバ ↓ GAS MCP サーバ（アクセストークンを管理） ↓ GA4 / Clarity ``` **アクセストークンの管理をGAS MCPサーバ側に寄せる設計です。**認証情報の置き場所を1箇所に固定することで、管理対象が分散するのを防ぎます。 ## 達成できたこと：プロンプトベースでのトークン自動発行 **リフレッシュトークンを用いたアクセストークンの自動発行が、プロンプトベースで安定稼働しています。** Google系APIのアクセストークンは1時間で切れます。利用者がその都度認証をやり直す必要があると、**「誰でも簡単に使える」という当初の目的が崩れます。** プロンプトを投げれば、裏側で必要なトークンが自動的に取得される。この状態になって初めて、**利用者が認証の存在を意識せずに済みます。** ## 「誰でも使える」ために必要だったこと | 目指した状態 | そのために必要なこと | | --- | --- | | ローカル環境の整備が不要 | リモートホスティング | | 認証を意識しなくてよい | トークンの自動発行・更新 | | 安全に共有できる | 秘匿情報の管理設計 | **使いやすさは、裏側の設計をどれだけ引き受けるかで決まります。**利用者から見えない部分に手間をかけるほど、表側が簡単になります。 ## よくある質問 ### なぜ踏み台サーバを挟むのですか？ **アクセストークンの管理を1箇所に集約するためです。**認証情報の置き場所が分散すると、更新や管理が難しくなります。 ### リモート化で一番難しいのは何ですか？ **秘匿情報（キー）の管理とセッション維持の設計です。**ホスティング自体は難しくありませんが、ローカルでは存在しなかった問題が共有した瞬間に現れます。 ### 利用者は認証操作が必要ですか？ **不要にすることを目指しています。**リフレッシュトークンによるアクセストークンの自動発行がプロンプトベースで安定稼働しており、利用者が認証を意識せずに済む状態を作っています。 ## まとめ - ローカルMCPを誰でも使える形にするため、**踏み台MCPサーバ → GAS MCPサーバという構成**を設計 - **リフレッシュトークンによるアクセストークンの自動発行がプロンプトベースで安定稼働** - 実用化の鍵は**秘匿情報の管理とセッション維持の設計**。ホスティング自体は難しくない - **使いやすさは裏側の設計をどれだけ引き受けるかで決まる** 「誰でも使える」を実現するコストは、たいてい認証まわりに集中します。ここを設計に含めておくと、共有の段階で立ち止まらずに済みます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のデータ活用基盤づくりを支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 商談評価から主観を外す｜クロージングの受け答えをLLMでスコアリングする - URL: https://ai-katsu.jp/articles/sales-analysis-list-notification - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-22T00:00:00+00:00 - Tools: Zoom, Make, n8n - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: 営業 > 商談後の振り返り精度を上げるため、クロージング時の受け答えや質問の密度をLLMでスコアリングする仕組みを構築中です。担当者の感覚とは別軸の指標を持つことで比較可能な評価になります。あわせてリスト通知の不具合3件を解消し、分析の前提となる記入監視を安定化させた記録です。 商談の評価は、どうしても主観が入ります。「手応えがあった」「あまり刺さらなかった」という感覚は、人によって基準が違います。 この検証では、**クロージング時の受け答えや質問の密度をLLMでスコアリングすることで、主観を排除した商談評価**を目指しました。あわせて、運用中に見つかったリスト通知の不具合3件にも対応しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月〜12月（11/22〜12/19） | | やりたかったこと | 商談後の振り返り精度を向上させ、成約に至る具体的な要因を特定する | | 対応したこと | **リスト通知の不具合3件の解消**／HOT・COLDラベル付けロジックの改善 | | 結論 | **クロージング時の受け答えや質問の密度をLLMでスコアリングすることで、主観を排除した商談評価が可能** | | 分析方針 | 「実演有無」「活用事例の紹介有無」をタグ分類（業務-Gemini / Dify等）して分析 | | 状況 | 運用監視および分析モデル構築中 | > 本記事は自社での検証記録です。成約率の変化などの測定は行っていないため、数値は掲載していません。 ## 結論：スコアリングで主観を外す この段階で確認できた最も重要な点です。 **クロージング時の特定の受け答えや質問の密度をLLMでスコアリングすることで、主観を排除した商談評価が可能になります。** 営業の振り返りは、担当者本人の記憶と感覚に依存します。同じ商談でも、調子が良い日と悪い日では自己評価が変わります。**この揺れがある限り、データとして積み上がりません。** 一方、**「どんな質問を何回したか」「クロージングにどう返ってきたか」は、記録から機械的に判定できます。**ここをスコア化すれば、比較可能な数字になります。 感覚を否定するのではなく、**感覚とは別軸の指標を用意する**ということです。 ## 運用で見つかった不具合への対応 この期間の作業として、**リスト通知の不具合3件に対応し、アラート通知の不具合解消とリスト記入監視の安定化を達成しました。** 地味ですが、これは分析の前提条件です。**通知が正しく飛ばなければ記入漏れが起き、記入漏れがあれば分析できません。** 自動化は作った時点では完成せず、**運用しながら出てくる不具合を潰す期間が必ず必要になります。**この工程を見込まずにスケジュールを引くと、分析フェーズに入れません。 ## HOT/COLDラベルの精度改善 予約者へのラベル付けロジックも改善しています。事前の温度感判定が正確になるほど、**商談準備の力の配分が的確になります。** ## タグ分類による相関分析 成約率向上のための分析方針を確定しました。**「実演有無」や「活用事例の紹介有無」を、タグ分類（業務-Gemini / Dify等）と組み合わせて分析します。** 商材によって効く打ち手は変わります。全体を平均しても意味がないため、**タグで切り分けたうえで比較する**設計です。 ## コストの制約下での運用 実務的な補足として、**営業実演のMakeフローは無料枠内でのやりくりを継続しています。** ノーコードツールは実行回数に応じてコストが増えます。**検証段階では無料枠に収まるよう組み方を工夫し、本格運用の目処が立ってから有料化やコードへの移行を判断する**——という進め方です。 ## 横展開：講師評価への応用 この分析の枠組みは、営業以外にも使えます。**講師評価制度への応用可能性（n8n活用）を確認しました。** 「話し方を記録して、良い動きを特定する」という構造は、対象を変えても成立します。**一度作った分析の型は、他の領域に持っていけます。** ## よくある質問 ### 主観を排除するとはどういうことですか？ **担当者の感覚とは別軸の指標を用意するということです。**質問の回数やクロージングへの返答内容は記録から機械的に判定できるため、スコア化すれば比較可能な数字になります。 ### なぜ不具合対応に時間をかけるのですか？ **通知が飛ばなければ記入漏れが起き、記入漏れがあれば分析できないためです。**自動化は運用しながら不具合を潰す期間が必ず必要になります。 ### Makeの費用はどうしていますか？ **無料枠内でのやりくりを継続しています。**検証段階では無料枠に収まるよう組み方を工夫し、本格運用の目処が立ってから有料化やコード移行を判断する方針です。 ### 営業以外にも使えますか？ **講師評価制度への応用可能性を確認しています。**「話し方を記録して良い動きを特定する」という構造は、対象を変えても成立します。 ## まとめ - **クロージング時の受け答えや質問の密度をLLMでスコアリング**することで、主観を排除した商談評価が可能 - **リスト通知の不具合3件を解消**し、記入監視を安定化。分析の前提を整えた - 「実演有無」「活用事例の紹介有無」を**タグ分類と組み合わせて相関を分析**する方針を確定 - Makeフローは**無料枠内でやりくり**。本格運用の目処が立ってからコストの判断をする - 分析の型は**講師評価制度へ横展開**できる データに基づく評価を導入する目的は、感覚を否定することではありません。感覚と突き合わせられる別の軸を持つことで、議論が具体的になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の営業DXとAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 無料枠で自動投稿を回す｜画像生成API断念とRenderのスリープ問題への対処 - URL: https://ai-katsu.jp/articles/x-techjii-infra-image-policy - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-22T00:00:00+00:00 - Models: Imagen - Tools: X（旧Twitter） - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: マーケティング > Node.js + RenderでSNS自動投稿基盤を構築する中で、Google Cloudの課金契約エラーにより画像生成APIを断念し、固定画像の使い回しへ方針転換しました。あわせてRender無料版のスリープ仕様による不定期な疎通エラーも判明。外部要因の制約を前提に組む設計の必要性をまとめています。 SNSの自動投稿基盤をNode.js + Renderで構築する中で、**2つの外部要因に足を止められました。**画像生成APIの課金契約エラーと、無料ホスティングのスリープ仕様です。 どちらも自分たちの実装の問題ではありません。それでも運用は止まります。**制約を受け入れたうえで、どう回すかを決めた記録**です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月〜12月（11/22〜12/19） | | 使用ツール | Node.js / Render（無料版）/ Imagen・Nano Banana | | やりたかったこと | 有益なAI情報を自動でキャラクター口調に変換して発信する仕組みを構築する | | 方針転換 | **Google Cloudの課金契約エラーにより画像生成APIの利用を一旦断念。「固定画像の使い回し」による自律運用にシフト** | | 技術的な発見 | **Render無料版の「スリープ」仕様により、Discord通知やAPI実行に疎通エラーが発生する場合がある** | | 状況 | 基盤移行および運用ルール策定フェーズ | > 本記事は自社での検証記録です。投稿の反応などの測定は行っていないため、数値は掲載していません。 ## 制約1：画像生成APIが使えなかった ImagenやNano Bananaによる画像生成を組み込む計画でしたが、**Google Cloudの課金契約におけるエラーにより、利用を一旦断念しました。** 実装の問題ではなく、契約・課金まわりの制約です。**コードが書けていても、アカウント側の条件が揃わなければAPIは叩けません。** ### 対応：固定画像の使い回しに切り替える ここで判断したのは、**画像生成を待たずに運用を始める**ことでした。当面は「固定画像の使い回し」による自律運用にシフトしています。 毎回違う画像を生成できるのが理想ですが、**画像が付いているだけでもタイムライン上での見え方は変わります。**完璧な形を待って停止するより、劣化版で回し続けるほうが得るものが多いという判断です。 **結果として、テキスト＋固定画像による自動投稿ロジックは完成しています。** ## 制約2：Render無料版のスリープ もう一つ、運用してみて分かった落とし穴です。 **Render無料版の「スリープ」等の仕様により、Discord通知やAPI実行に疎通エラーが発生する場合があることを特定しました。** 無料枠のホスティングは、一定時間アクセスがないとインスタンスが停止します。次のリクエストで起動し直しますが、**その起動待ちの間にタイムアウトすると処理が失敗します。** 定期実行の仕組みでは、これが不定期な失敗として現れます。**コードは正しいのに、たまに動かない**——原因が分かりにくい種類のトラブルです。 ## 無料枠で運用するときに見込むべきこと | 制約 | 現れ方 | | --- | --- | | インスタンスのスリープ | 不定期な疎通エラー。原因が分かりにくい | | 課金契約の条件 | コードが正しくてもAPIが使えない | **検証段階では無料枠で始めるのが合理的ですが、「たまに失敗する」ことを前提に設計しておく必要があります。**リトライを入れる、失敗を検知して通知する、といった備えがないと、静かに止まっていることに気づけません。 ## よくある質問 ### なぜ画像生成をやめたのですか？ **Google Cloudの課金契約におけるエラーによるものです。**実装の問題ではなく、アカウント側の条件が揃わなかったため一旦断念しました。当面は固定画像の使い回しで運用しています。 ### 固定画像でも意味がありますか？ **画像が付いているだけでタイムライン上の見え方は変わります。**毎回生成できるのが理想ですが、完璧な形を待って停止するより、劣化版で回し続けるほうが得るものが多いという判断です。 ### Render無料版で何が起きますか？ **スリープ仕様により、Discord通知やAPI実行で疎通エラーが発生する場合があります。**一定時間アクセスがないとインスタンスが停止し、起動待ちの間にタイムアウトすることがあります。 ### 無料枠で運用してよいですか？ 検証段階では合理的です。ただし**「たまに失敗する」ことを前提に、リトライや失敗検知の仕組みを入れておく**必要があります。 ## まとめ - **Google Cloudの課金契約エラーにより画像生成APIを断念**。固定画像の使い回しで運用を継続 - 完璧な形を待つより、**劣化版で回し続けるほうが得るものが多い** - **Render無料版のスリープ仕様により、不定期な疎通エラーが発生**する - 無料枠での運用は**「たまに失敗する」前提の設計**が必要。リトライと失敗検知を入れる 自動化の運用では、自分たちの実装以外の要因で止まることがよくあります。外部サービスの制約を前提に組めるかどうかで、稼働率が変わります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## ローカルMCPをリモート化する｜移行の焦点は機能ではなく認証にある - URL: https://ai-katsu.jp/articles/marketing-remote-mcp-server - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-08T00:00:00+00:00 - Tools: MCP, Google Apps Script, Vercel - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: マーケティング > 「作った人のPCでしか動かない」ローカルMCPを、誰でもどこからでも使えるリモート構成へ移行しました。踏み台MCPサーバを経由してGAS MCPサーバへ接続する設計です。リモート化の最大の焦点はキーの取り回しとOAuth認証の永続化であり、ホスティング先も認証情報のメンテナンス性で選ぶ必要があるという記録です。 ローカルMCPは手軽に始められますが、**「作った人のPCでしか動かない」**という弱点があります。組織の仕組みにするには、この依存を外す必要があります。 誰でもどこからでもマーケティングデータにアクセスできるよう、**踏み台MCPサーバを経由してGAS MCPサーバへ接続する「リモートMCP構成」**の設計・構築を進めました。リモート化にあたって焦点になるのは、認証まわりです。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月（11/8〜11/21） | | 使用ツール | MCP / GAS / Render / Vercel | | やりたかったこと | ローカル環境に依存せず、誰でもどこからでもマーケティングデータ（GA4/Clarity）にアクセス・分析できる環境を作る | | 構成 | **踏み台MCPサーバを経由してGAS MCPサーバへ接続するリモートMCP構成** | | 達成できたこと | 1時間で切れるアクセストークンのリフレッシュ処理の実装成功／ローカルMCP環境の共有完了 | | 焦点 | **「キーの取り回し」と「OAuth認証の永続化」** | | 状況 | アーキテクチャ設計および移行中 | > 本記事は自社での検証記録です。工数削減などの定量測定は行っていないため、数値は掲載していません。 ## 結論：リモート化の焦点は認証にある この移行で最も重要な論点がこれです。 **リモートMCP化にあたっては「キーの取り回し」と「OAuth認証の永続化」が最大の焦点となります。** ローカルで動かしている間は、認証情報は自分のPCにあります。誰と共有するかを考える必要もありません。ところがリモート化すると、**「誰の認証情報で、どこに置いて、どう更新し続けるか」を設計しなければなりません。** MCPサーバをホスティングに載せること自体は難しくありません。**難しいのは、そこに認証情報を安全に持たせ、切れないように保つことです。** ## 構成：踏み台を挟む ``` クライアント（誰のPCからでも） ↓ 踏み台 MCP サーバ（Render / Vercel） ↓ GAS MCP サーバ ↓ GA4 / Clarity のデータ ``` 直接繋ぐのではなく踏み台を経由する構成にしています。**認証情報を集約する場所を1箇所に固定できる**ため、管理の対象が分散しません。 ### ホスティング先の検討 ホスティング先として**RenderやVercelを検討しました。判断軸は認証情報のメンテナンス性です。** 環境変数の管理方法、更新のしやすさ、アクセス制御。**「どこで動かすか」を性能やコストだけで決めると、あとで認証まわりの運用が苦しくなります。** ## 達成できたこと - **1時間で切れるアクセストークンのリフレッシュ処理の実装成功** — 定期実行の前提条件 - **ローカルMCP環境の共有完了** — 個人の手元だけで動く状態からの一歩 Google系APIのアクセストークンは1時間で期限切れになります。**これを自動更新できないと、リモートで動かしても止まります。**ここをクリアできたことが、移行の土台になりました。 ## ローカルからリモートへ移行する意味 | | ローカルMCP | リモートMCP | | --- | --- | --- | | 始めやすさ | 手軽 | 設計が必要 | | 利用できる人 | 構築した本人のみ | 誰でも | | 認証情報の管理 | 手元にあるだけ | **設計対象になる** | | 組織の仕組みとして | 成立しにくい | 成立する | **ローカルで価値を確認してから、リモートに移して全員が使える形にする。**この順序自体は正しい進め方です。ただし移行時に認証の設計が必要になることは、最初から見込んでおくべきでした。 ## よくある質問 ### なぜ踏み台サーバを挟むのですか？ **認証情報を集約する場所を1箇所に固定するためです。**直接繋ぐ構成にすると、管理対象が分散して運用が難しくなります。 ### ホスティング先はどう選びましたか？ **認証情報のメンテナンス性を判断軸に、RenderやVercelを検討しました。**性能やコストだけで決めると、後から認証まわりの運用が苦しくなります。 ### アクセストークンの1時間制限は？ **リフレッシュ処理の実装に成功しています。**これができないとリモートで動かしても止まってしまうため、移行の前提条件になります。 ### すでに誰でも使える状態ですか？ **現在はアーキテクチャ設計および移行中です。**ローカルMCP環境の共有までは完了しています。 ## まとめ - ローカルMCPは手軽だが**「作った人のPCでしか動かない」**。組織の仕組みにはリモート化が必要 - 構成は**踏み台MCPサーバを経由してGAS MCPサーバへ接続**。認証情報を1箇所に集約できる - リモート化の最大の焦点は**「キーの取り回し」と「OAuth認証の永続化」** - ホスティング先は**認証情報のメンテナンス性**を軸に選ぶ - **1時間で切れるアクセストークンのリフレッシュ処理**が移行の前提条件 ローカルで動くものを組織の仕組みに変える工程では、機能ではなく認証と権限が主な課題になります。ここを見込んでおくと、移行の見積もりが現実的になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のデータ活用基盤づくりを支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIツールの更新を自動で追う｜RSSだけでは「何が変わったか」が分からない問題 - URL: https://ai-katsu.jp/articles/ai-info-curriculum-update-v2 - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-08T00:00:00+00:00 - Models: Microsoft Copilot - Tasks: ナレッジ活用・RAG, 業務プロジェクト - Domain: 教育・研修 > 主要AIツールのリリースノートをLangGraphで自動監視し、Discordへ通知する仕組みを構築中です。実装の過程で、提供元によってはRSSに詳細リンクしか含まれず中身を解析できないという課題が判明。AIがリンク先まで巡回してスクレイピング・要約するステップを追加する方針に至った経緯をまとめています。 AIツールのアップデートは、目視で追うには量が多すぎます。研修教材やコミュニティに反映すべき変更を見落とすと、古い情報を教えることになりかねません。 LangGraphを使い、**各ツールのリリースノートを自動監視してDiscordへ通知する仕組み**を構築中です。実装を進める中で、RSSだけでは情報が足りないという問題に突き当たりました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月（11/8〜11/21） | | 使用ツール | LangGraph / RSS / Discord | | やりたかったこと | 主要AIツールのアップデートを目視で追う限界を解消し、教材への反映が必要な情報を自動抽出する | | 発生した課題 | **Microsoft Copilot等のRSSでは「詳細リンク」の情報しか取れず、中身の解析が不十分** | | 対応方針 | **詳細リンク先までAIが巡回してスクレイピング・要約するステップをロジックに追加** | | 状況 | ロジック修正フェーズ | > 本記事は自社での検証記録です。情報収集工数の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：RSSは「更新があった」しか教えてくれない この検証で突き当たった問題がこれです。 **Microsoft Copilot等のRSSでは「詳細リンク」の情報しか取得できず、中身の解析が不十分でした。** RSSフィードの中身は、提供元によって粒度が大きく違います。本文まで含まれているものもあれば、**タイトルとリンクだけというものもあります。**後者の場合、「何かが更新された」ことは分かっても、「何が変わったか」は分かりません。 教材への反映が必要かを判断するには、中身を読む必要があります。**リンクだけ通知されても、結局は人が開いて確認することになり、自動化の意味が薄れます。** ### 対応：AIにリンク先まで巡回させる 解決策として、**詳細リンク先までAIが巡回して内容をスクレイピング・要約するステップをロジックに追加する**方針としました。 ``` RSS を監視 ↓ 更新を検知（タイトル＋リンクのみ） AI が詳細リンク先を巡回 ↓ 内容をスクレイピング・要約 Discord へ通知（何が変わったかが分かる形で） ``` **「取れる情報が足りないなら、取りに行くステップを足す」**という単純な発想ですが、ここを省くと通知が実用にならないという判断です。 ## なぜLangGraphを使うのか この構成は、単純な「取得して通知」ではありません。**取得 → 判定 → 巡回 → 要約 → 通知**という複数のステップを、条件に応じて進める必要があります。 RSSに本文が含まれていれば巡回は不要ですし、含まれていなければ巡回が必要。**提供元によって処理を分岐させる構造**になります。こうしたステップと分岐を管理するのがLangGraphの役割です。 ## この仕組みが解決する課題 教材やコミュニティを運営する立場では、次の問題が常にあります。 - ツールの仕様変更に気づかず、古い手順を教えてしまう - アップデートを追う担当者に負荷が集中する - 「重要な変更」と「些細な変更」の切り分けに時間がかかる **中身まで要約された状態で通知が届けば、3つ目の切り分けが速くなります。**これが今回、リンク巡回のステップを追加する理由です。 ## よくある質問 ### RSSだけでは何が足りないのですか？ **提供元によっては「詳細リンク」の情報しか含まれていないためです。**更新があったことは分かっても、何が変わったかが分かりません。判断するには中身を読む必要があります。 ### どう対応するのですか？ **AIが詳細リンク先まで巡回して、内容をスクレイピング・要約するステップをロジックに追加します。**取れる情報が足りないなら、取りに行く工程を足すという方針です。 ### なぜLangGraphを使うのですか？ **提供元によって処理を分岐させる必要があるためです。**RSSに本文が含まれていれば巡回は不要、なければ必要——といった条件分岐を含む複数ステップの処理を管理します。 ### すでに運用に乗っていますか？ **現在はロジック修正フェーズです。**RSS監視とDiscord通知の基本部分は動いていますが、リンク巡回のステップを追加している段階です。 ## まとめ - LangGraphでAIツールのリリースノートを自動監視し、Discordへ通知する仕組みを構築中 - **RSSは提供元によって粒度が違う。**詳細リンクしか含まれない場合、中身の解析ができない - 対応は**AIが詳細リンク先まで巡回してスクレイピング・要約するステップの追加** - 「更新があった」だけの通知では、結局人が開いて確認することになり自動化の意味が薄れる 情報収集の自動化では、通知が届くことより「読んだだけで判断できるか」が価値を決めます。中身がなければ、通知は作業を増やすだけになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のナレッジ管理とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIの評価精度はプロンプトで決まる｜書類選考を現場の判断基準に近づける方法 - URL: https://ai-katsu.jp/articles/recruit-agent-dify-advanced - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-08T00:00:00+00:00 - Tools: Dify - Tasks: ナレッジ活用・RAG, 業務プロジェクト - Domain: 採用・人事 > Dify書類選考エージェントの評価を現場の判断基準に近づけるため、モデルではなくプロンプトの調整に注力しました。求人ごとの判定軸を明確にするには、会社・事業情報の詳細な注入が必要です。採用担当者が当たり前に使っている前提を文章化する作業が評価精度を決めるという知見をまとめています。 Difyで書類選考のスコアリングを組んだあと、次に取り組んだのは**評価を「現場の判断基準」に近づける**ことでした。動くものはできていても、出てくる評価が採用担当の感覚とずれていては使えません。 取った手段は、モデルの変更でも仕組みの作り直しでもなく、**プロンプトへの情報注入**でした。この地味な作業が、評価の精度を決めています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月（11/8〜11/21） | | 使用ツール | Dify | | やりたかったこと | Dify書類選考エージェントの評価を、より現場の判断基準に近づける | | 実装したもの | **5項目（各星1〜5）での評価と、合計点に基づく「星の数」の可視化** | | 行った対応 | 求人ごとの判定軸を明確にするため、**会社・事業情報の詳細なプロンプト注入を実施** | | 状況 | プロンプトエンジニアリングフェーズ | > 本記事は自社での検証記録です。評価精度の数値測定は行っていないため、正答率などの数値は掲載していません。 ## 結論：判定軸は求人ごとに与える この段階で取り組んだ核心がこれです。 **求人ごとに「バックオフィス向け」「AI講師向け」といった判定軸を明確にするため、会社・事業情報の詳細なプロンプト注入を実施しました。** 同じ職務経歴書でも、募集している職種によって評価は変わります。バックオフィスなら正確さや継続性、AI講師なら伝える力や技術理解——見るべき点がまったく違います。 この違いは、**プロンプトに書かなければAIには伝わりません。**「優秀な人を選んで」では、汎用的な優秀さで判定されます。 ### 何を注入するのか - **会社情報** — どんな組織で、何を大事にしているか - **事業情報** — 何をやっている会社で、その職種がどこを担うか - **職種ごとの判定軸** — この求人では何を重視するか **採用担当者が頭の中で当たり前に使っている前提を、文章として書き出す作業です。**手間はかかりますが、ここを省くと評価が現場の感覚から離れます。 ## 評価の可視化：5項目 × 星1〜5 出力の形式も整えました。**5項目それぞれを星1〜5で評価し、合計点に基づいて総合の「星の数」を表示します。** | 設計 | 狙い | | --- | --- | | 項目ごとの星評価 | どこが強く、どこが弱いかが一目で分かる | | 合計点からの総合星 | 優先順位をつけて見る順番を決められる | **数値のままだと解釈が人によって変わるため、星に丸めています。**「7点」と言われるより「星3」のほうが、判断が速くなります。 ## この取り組みの位置づけ この選考エージェントは、Indeed APIの利用が停滞している状況で**代替として先行させたもの**です。応募者情報の取得が自動化できなくても、評価の部分だけで工数は削減できます。 現在はプロンプトエンジニアリングのフェーズにあり、**仕組みを増やすのではなく、渡す情報を磨く段階**です。 ## よくある質問 ### なぜモデルを変えずにプロンプトを調整するのですか？ **問題がモデルの性能ではなく、渡している情報の不足にあるためです。**求人ごとの判定軸を伝えなければ、どのモデルを使っても汎用的な評価になります。 ### どんな情報を注入するのですか？ **会社情報、事業情報、そして職種ごとの判定軸です。**採用担当者が頭の中で当たり前に使っている前提を、文章として書き出します。 ### なぜ点数ではなく星なのですか？ **数値のままだと解釈が人によって変わるためです。**星に丸めることで判断が速くなります。項目ごとの星で強弱を、合計点からの総合星で優先順位を見る設計です。 ### 実運用に乗っていますか？ **現在はプロンプトエンジニアリングのフェーズです。**評価を現場の判断基準に近づける調整を進めています。 ## まとめ - Dify書類選考エージェントを**現場の判断基準に近づける**ため、プロンプトの調整に注力 - 求人ごとの判定軸を明確にするには、**会社・事業情報の詳細な注入が必要** - 採用担当者が**当たり前に使っている前提を文章化する**作業が、評価精度を決める - 出力は**5項目×星1〜5と、合計点による総合星**で可視化。数値より判断が速くなる AIの評価精度を上げようとすると、モデルや仕組みに目が向きがちです。しかし多くの場合、足りないのは渡している前提情報のほうです。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の採用業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## ノーコードからNode.jsへ移行した理由｜画像付き自動投稿でn8nの限界に当たった - URL: https://ai-katsu.jp/articles/x-techjii-bcrew-autonomous - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-08T00:00:00+00:00 - Models: Gemini, Imagen - Tools: X（旧Twitter） - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: マーケティング > AI情報の収集から発信までを完全自動化する過程で、n8nでは画像生成・投稿の自由度が足りず、Node.js基盤（Render公開）へ移行しました。Gemini APIのImagen/Nanoで画像を生成し、テキスト＋画像付きツイートの自動投稿に成功。「回避策がコードを書くより複雑になったら移行」という判断基準をまとめています。 SNSの自動投稿をノーコードツールで組み始めると、あるところで頭打ちになります。テキストだけなら問題ありませんが、**画像を生成して添えようとした瞬間に自由度が足りなくなる**のです。 この検証では、n8nベースの構成からNode.js基盤へ移行し、**テキスト＋画像付きツイートの自動投稿**を実現しました。ノーコードを捨てる判断をどこで下したかを共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月（11/8〜11/21） | | 使用ツール | Node.js / Render / X API / Gemini API（Imagen・Nano） | | やりたかったこと | 最新AI情報の収集・加工・発信を完全に自動化し、24時間稼働の運用体制をつくる | | 方針転換 | **n8nのみでは画像生成・投稿の自由度が低いため、Node.js基盤へ舵を切った** | | 達成できたこと | テキストおよび**画像付きツイートの成功確認**／6時間間隔でのXリスト取得とタグ自動選別ロジック | | 状況 | 基盤移行および画像投稿検証フェーズ | > 本記事は自社での検証記録です。エンゲージメントの変化などの測定は行っていないため、数値は掲載していません。 ## 結論：画像生成でノーコードの限界に当たった この移行の理由は明確です。 **n8nのみでは、画像生成・投稿の自由度が低いという判断に至りました。** ノーコードツールは、用意されたモジュールの範囲では非常に速く組めます。テキストを取得して要約して投稿する、という流れであれば問題ありません。 しかし**画像を生成し、内容に合わせて調整し、投稿に添える**——この工程はモジュールの組み合わせでは表現しきれませんでした。細かい制御が必要な部分ほど、ノーコードの制約が効いてきます。 そこでNode.jsを基盤としたシステム構築へ切り替え、Renderで公開する構成にしました。 ## 構成 ``` 6時間間隔で X のリストを取得 ↓ 独自ロジックでエンゲージメント計算 → 上位5件を抽出 Gemini API（Imagen / Nano）で画像生成 ↓ Node.js（Render で公開） ↓ X API でテキスト＋画像を投稿 ``` **テキストメッセージと画像付きツイートの両方で、投稿の成功を確認しています。** ## ノーコードから移行する判断基準 今回の経験から、切り替えを検討すべきタイミングを整理します。 | 状況 | 判断 | | --- | --- | | 用意されたモジュールで組める | ノーコードのまま | | 細かい制御が必要になってきた | 移行を検討 | | **回避策の実装がコードを書くより複雑** | **移行すべき** | **ノーコードで無理やり実現するための工夫が、素直にコードを書くより複雑になったら、それが移行のサインです。**今回の画像生成・投稿がまさにその状態でした。 ## 選別ロジックは維持している 基盤は変わりましたが、**6時間間隔でXのリストを取得し、エンゲージメント計算で上位5件を抽出してタグ付けする**という選別ロジックはそのまま引き継いでいます。 新着順ではなくエンゲージメント基準で選ぶことが、自動投稿の質を担保する要です。**実行環境を変えても、この設計思想は変えていません。** ## よくある質問 ### なぜn8nをやめたのですか？ **画像生成・投稿の自由度が低かったためです。**テキストのみの投稿であればn8nで足りますが、画像を生成して内容に合わせて調整する工程はモジュールの組み合わせでは表現しきれませんでした。 ### ノーコードからコードへ移るタイミングは？ **ノーコードで実現するための回避策が、コードを書くより複雑になったときです。**今回の画像生成・投稿がその状態でした。 ### 画像はどう生成していますか？ **Gemini APIのImagen・Nanoを使用しています。**テキストと画像の両方を含むツイートの投稿成功を確認済みです。 ### どこで動かしていますか？ **Node.jsで実装し、Renderで公開しています。**24時間稼働を前提とした構成です。 ## まとめ - n8nでは**画像生成・投稿の自由度が低く**、Node.js基盤（Render公開）へ移行 - **テキスト＋画像付きツイートの自動投稿に成功**。画像生成はGemini API（Imagen/Nano） - 移行の判断基準は**「回避策がコードを書くより複雑になったとき」** - 基盤は変えても**エンゲージメント基準の選別ロジックは維持**。設計思想は実行環境と独立している ノーコードは着手を速くしますが、要件が細かくなるほど制約が効いてきます。どこで乗り換えるかを見極められると、無駄な作り込みを避けられます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## トップ営業の動きを項目に分解する｜デモのタイミングと成約率の相関を測る仕組み - URL: https://ai-katsu.jp/articles/sales-analysis-demo-automation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-08T00:00:00+00:00 - Tools: Zoom, Make, Google Apps Script - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: 営業 > 商談の質を可視化し、成約率と実演（デモ）・ヒアリング時間の相関を特定する取り組みです。ヒアリング時間や質問密度、実演タイミングをLLMで分析するプロンプトを構築し、予約者へのHOT/COLD自動ラベル付けも実装。属人的な「うまさ」を再現可能な項目に分解する設計をまとめています。 「デモを見せた商談は決まりやすい」——営業の現場では感覚的に語られる話です。しかし本当にそうなのか、どのタイミングで見せるのが効くのかは、データがなければ確かめられません。 商談の質を可視化し、**成約率と「実演（デモ）」「ヒアリング時間」の相関を特定する**取り組みを進めています。あわせて、予約者への自動ラベル付け（HOT/COLD）や、実演時のワークフローも構築しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月（11/8〜11/21） | | 使用ツール | Zoom / Make / GAS / LLM | | やりたかったこと | 商談後のリスト記入漏れ防止と、トップ営業の動き（フレーズ、実演タイミング）の標準化 | | 稼働したもの | **リスト記入アラートとDiscordへの自動通知が安定稼働** | | 実装したもの | 予約者への**自動ラベル付け（HOT/COLD）**／営業実演時のMakeワークフロー | | 状況 | 運用監視および高度分析フェーズ | > 本記事は自社での検証記録です。成約率の変化などの測定は行っていないため、数値は掲載していません。 ## 結論：トップ営業の動きを項目に分解する この取り組みの狙いは、**属人的な「うまさ」を再現可能な項目に落とすこと**です。 具体的には、次の要素をLLMに分析させるプロンプトを構築しました。 - **商談中のヒアリング時間** — どれだけ相手の話を聞けているか - **質問の密度** — 踏み込んだ質問ができているか - **実演（デモ）のタイミング** — いつ見せているか - **使っているフレーズ** — どんな言い回しが効いているか **「あの人はうまい」で終わらせず、何がうまいのかを分解する。**分解できれば、他のメンバーにも渡せます。これが標準化の実質的な中身です。 ## HOT/COLDの自動ラベル付け 商談前の段階でも仕込みを入れました。**予約者への自動ラベル付け（HOT/COLD）**です。 すべての商談に同じ準備をするのは非効率です。**温度感が事前に分かれば、力の入れどころを配分できます。**これが自動で付くようになると、営業側の判断が速くなります。 ## 実演用のワークフロー **営業実演時のMakeワークフローを構築し、動作確認まで完了しています。** デモは、その場の準備に手間がかかる工程です。ここを仕組み化しておくと、**「デモを見せるかどうか」の判断に、準備コストが影響しなくなります。**本来は相手にとって必要かで決めるべきものです。 ## 土台として先に片付けたこと 分析の前段として、**リスト記入に関するアラート通知とDiscordへの自動通知が安定稼働に入っています。** 記入されていないデータは分析できません。**「デモの有無と成約率の相関」を見ようとしても、デモの有無が記録されていなければ何も分かりません。**アラートで記入漏れを防ぐことが、分析の前提になります。 ## 横展開の検討 この仕組みの応用として、**講師評価制度への横展開（n8n活用）**の検討を開始しています。 「話し方を分析して、良い動きを特定する」という構造は、営業に限りません。**研修講師の評価にも同じ考え方が使えます。**一度作った分析の枠組みは、対象を変えて再利用できます。 ## よくある質問 ### 何を分析しているのですか？ **商談中のヒアリング時間、質問の密度、実演のタイミング、使っているフレーズです。**これらと成約率の相関を見ることで、トップ営業の動きを再現可能な形に分解します。 ### HOT/COLDはどう判定していますか？ **予約者への自動ラベル付けとして実装しています。**事前に温度感が分かることで、商談準備の力の入れどころを配分できます。 ### なぜリスト記入のアラートが必要なのですか？ **記入されていないデータは分析できないためです。**デモの有無と成約率の相関を見ようとしても、デモの有無が記録されていなければ何も分かりません。分析の前提条件です。 ### 成約率は上がりましたか？ **この検証では成約率の測定は行っていません。**現在は運用監視および高度分析のフェーズです。 ## まとめ - 商談の質を可視化し、**成約率と実演・ヒアリング時間の相関を特定**する取り組みを推進 - ヒアリング時間、質問密度、実演タイミング、フレーズを**LLMで分析するプロンプトを構築** - 予約者への**HOT/COLD自動ラベル付け**で、商談準備の力の配分を可能に - 実演用のMakeワークフローで、**準備コストがデモ実施の判断に影響しない**状態をつくる - 前提として**リスト記入アラートが安定稼働**。記入されないデータは分析できない - 同じ枠組みを**講師評価制度へ横展開**する検討を開始 営業の標準化は「うまい人のやり方を真似る」だけでは進みません。何がうまいのかを項目に分解して、初めて渡せるものになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の営業DXとAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Google Workspace Flowsはどこまで使えるか｜GASと組む「ハイブリッド型自動化」が現実解 - URL: https://ai-katsu.jp/articles/google-workspace-flows - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-01T00:00:00+00:00 - Models: Gemini - Tools: Google Workspace, Google Apps Script - Tasks: 業務自動化・ワークフロー, ツール検証 > Google Workspaceに新搭載されたFlowsで、社内業務をノーコードでどこまで完結できるか検証しました。トリガーの限定・英語出力・ドキュメント直接操作の未実装により単体では実用シーンが限られる一方、FlowsからGAS関数を呼び出すハイブリッド構成が有効。全体の流れはFlows、複雑な処理はGASという分担をまとめています。 Google Workspaceに新しく搭載された「Flows」は、ノーコードで業務フローを組める機能です。すでにWorkspaceを使っている企業にとっては、追加投資なしで試せる自動化の入口になります。 議事録作成やフォーム処理をどこまで完結できるか検証したところ、**単体では実用シーンが限られる一方、GASと組み合わせた「ハイブリッド型自動化」が有効**だと分かりました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月（11/1〜11/7） | | 使用ツール | Google Workspace Flows / Gemini / GAS | | やりたかったこと | ノーコードで社内業務（議事録作成、フォーム処理等）をどこまで完結できるか | | 制約 | **トリガーが限定的で、出力が英語。**Googleドキュメントの直接操作も未実装（調査時点） | | 有効だった使い方 | **FlowsからGAS関数を呼び出す「ハイブリッド型自動化」** | | 判定 | 完了（一部機能の日本語化・機能追加待ち） | > 本記事は自社での検証記録です。工数削減の定量測定は行っていないため、数値は掲載していません。調査時点の仕様に基づく内容です。 ## 結論：Flowsで骨組み、GASで中身 この検証で確立した使い分けがこれです。 **Flowsで全体のワークフローを組み、分岐のネストや複雑な計算はGASに任せる。**この分担が、最もメンテナンス性が高いという結論になりました。 ノーコードツールは、条件分岐が増えるほど画面上の構造が複雑になります。ネストが深くなると、後から見て何をしているか分からなくなる。**これはFlowsに限らず、ノーコード全般の弱点です。** 一方、複雑なロジックはコードで書いたほうが読みやすくなります。**「全体の流れは目で見える形で、細かい処理はコードで」という切り分けが噛み合います。** ### ハイブリッド型自動化の有効性 実際に、**FlowsからGASの関数を呼び出し、複雑なデータ加工を委譲する構成の有効性を確認しました。**実装には `appsscript.json` の編集を伴います。 ``` Google Workspace Flows（全体のワークフロー） ↓ GAS関数を呼び出し GAS（分岐のネスト・複雑な計算・データ加工） ↓ 処理結果を Flows に返す ``` ## 現時点の制約 単体での実用シーンが限られる理由が、次の3点です。 - **トリガーが限定的** — 起動条件の選択肢が少ない - **出力が英語** — 日本語環境での利用に支障が出る - **Googleドキュメントの直接操作が未実装**（調査時点） 特に3つ目は、議事録作成のような用途では効いてきます。ドキュメントを直接扱えないため、**現時点ではスプレッドシートやWebhookを介した連携を主軸にする**という方針にしました。 ## 試した3つのシナリオ 1. **Google Meet要約のドキュメント化** 2. **フォーム送信時のスプレッドシート自動処理** 3. **Google ChatとDiscordの連携** いずれもWorkspace内で完結する定型業務です。**すでにWorkspaceを使っている環境なら、追加のツール導入なしに着手できる**点は評価できます。 ## いつ本格導入すべきか 現時点では「一部機能の日本語化・機能追加待ち」という判定です。**出力の日本語化とGoogleドキュメントの直接操作が実装されれば、実用範囲が大きく広がります。** それまでの間は、**ハイブリッド型で使える部分から試しておく**のが現実的です。全体の設計をFlowsで組んでおけば、機能追加後にそのまま範囲を広げられます。 ## よくある質問 ### ノーコードだけで業務自動化は完結しますか？ **現時点では限られます。**トリガーが限定的で出力が英語という制約があるためです。GASと組み合わせるハイブリッド構成にすると、実用範囲が広がります。 ### なぜGASと組み合わせるのですか？ **分岐のネストや複雑な計算は、ノーコードで組むとメンテナンス性が落ちるためです。**全体の流れはFlowsで見える形にし、複雑な処理はGASに委譲する分担が最も扱いやすくなります。 ### 議事録の自動作成に使えますか？ **調査時点ではGoogleドキュメントの直接操作が未実装でした。**スプレッドシートやWebhookを介した連携を主軸にする必要があります。 ### 日本語では使えませんか？ **出力が英語であるため、日本語環境での実用シーンは限られます。**今後の日本語対応を待つ必要があります。 ## まとめ - Google Workspace Flows単体では、**トリガーの限定・英語出力・ドキュメント直接操作の未実装**により実用シーンが限られる - 有効だったのは**FlowsからGAS関数を呼び出す「ハイブリッド型自動化」** - 最もメンテナンス性が高いのは**「Flowsで全体の流れ、GASで複雑な処理」**という分担 - 現時点ではスプレッドシートやWebhookを介した連携を主軸とし、**機能追加を待つ**方針 ノーコードツールは「全部これで済ませる」と考えると詰まります。得意な範囲を見極めて、苦手な部分は別の手段に渡すほうが結果的に長く使えます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## RAGは50行で動く｜Gemini APIのFile Searchツールでベクトル基盤なしに実装する - URL: https://ai-katsu.jp/articles/gemini-file-search-rag - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-11-01T00:00:00+00:00 - Models: Gemini - Tasks: ナレッジ活用・RAG, ツール検証 > 大量の独自ドキュメントを参照するRAG環境を、Vertex AI等の基盤なしにAPIのみで構築できるか検証しました。Gemini APIのFile Searchツールを使うことで、約50行程度のコードで独自ソースに基づく回答生成を実装完了。ベクトルDBの構築も埋め込み管理も不要で、モック環境や小規模アプリには極めてコスパが高い構成です。 RAG（検索拡張生成）の構築は、大掛かりな作業だと思われがちです。ベクトルデータベースを用意して、埋め込みを作って、検索と生成を繋いで——という手順を想像すると、着手のハードルが上がります。 Gemini APIの**File Searchツール**を使えば、この工程が大幅に省けます。実際に試したところ、**約50行程度のコードで、独自ソースに基づく回答生成が実装できました。** ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年11月（11/1〜11/7） | | 使用ツール | Gemini API（File Search Tool）/ JavaScript（Node.js） | | やりたかったこと | 大量の独自ドキュメントを参照するRAG環境を、Vertex AI等の複雑な基盤なしにAPIのみで構築できるか | | 結果 | **約50行程度のコードでRAGの実装が完了** | | 評価 | 非エンジニアには難易度が高いが、**エンジニアにとってはモック環境や小規模アプリへのRAG実装として極めてコスパが高い** | | 判定 | 完了（小規模アプリ向け実装パターン確立） | > 本記事は自社での検証記録です。回答精度の数値評価や、大規模データでの性能測定は行っていないため、その数値は掲載していません。 ## 結論：50行でRAGが動く この検証で確認できた最も端的な事実がこれです。 **約50行程度のコードで、独自ソースに基づく回答生成（RAG）を実装完了しました。** 従来、RAGを自前で組もうとすると、ベクトルDBの選定と構築、埋め込みモデルの選択、チャンク分割の調整といった判断が次々に発生します。Vertex AIのような基盤を使えば整理されますが、それはそれで学習コストがかかります。 **File Searchツールは、この一連の工程をAPI側に寄せてくれます。**ファイルをアップロードし、ストアを構築し、問い合わせる。この3ステップだけです。 ## 実装の流れ ``` 1. ファイルをアップロード ↓ 2. ストアを構築 ↓ 3. API に問い合わせ → 独自ソースに基づく回答 ``` この検証ではJavaScript（Node.js）で実装しました。**ベクトルDBの用意も、埋め込みの管理も不要です。** ## 向いている用途 / 向かない用途 | | 評価 | | --- | --- | | **モック環境** | 極めてコスパが高い。すぐ動かせる | | **小規模アプリへのRAG実装** | 同上。基盤構築のコストを払わずに済む | | 非エンジニアの利用 | **難易度が高い**。コードを書く前提 | **「RAGを試したいが、基盤構築から始める余裕はない」という状況に最も噛み合います。**まず動くものを作って価値を確認し、必要なら後から本格的な基盤に移す、という進め方が取りやすくなります。 ## 非エンジニアには向かない 正直に書いておくと、**非エンジニアには難易度が高い**という評価です。APIを叩くコードを書く必要があるため、ノーコードで完結するものではありません。 社内のナレッジ活用を非エンジニアだけで進めたい場合は、NotebookLMのようなツールのほうが噛み合います。**誰が使うのかで、選ぶべき手段は変わります。** ## よくある質問 ### ベクトルデータベースは不要ですか？ **不要です。**File Searchツールがファイルのアップロードからストア構築までを担うため、自前でベクトルDBを用意する必要がありません。 ### Vertex AIとどちらを使うべきですか？ **規模と目的によります。**モック環境や小規模アプリであれば、File Searchツールのほうが圧倒的に速く着手できます。大規模な本番運用では、基盤側の機能が必要になる場面が出てくると考えられます。 ### 非エンジニアでも使えますか？ **難易度が高いです。**APIを叩くコードを書く前提のため、ノーコードで完結しません。非エンジニア中心で進めるなら、NotebookLMなど別の選択肢を検討してください。 ### 大量のドキュメントでも動きますか？ **この検証では大規模データでの性能測定は行っていません。**「小規模アプリ向けの実装パターン確立」という位置づけです。 ## まとめ - Gemini APIのFile Searchツールで、**約50行程度のコードでRAGを実装できた** - ベクトルDBの構築や埋め込みの管理といった**基盤構築の工程が不要** - **モック環境や小規模アプリへのRAG実装としてコスパが極めて高い** - ただし**非エンジニアには難易度が高い**。コードを書く前提の手段 RAGは「大掛かりなもの」という印象がありますが、規模を絞れば短時間で動かせます。まず小さく作って価値を確認する、という進め方が取りやすくなりました。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のナレッジ活用とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 広告数値をプロンプト一つで取得しAIと議論する｜ローカルMCPで作る分析環境 - URL: https://ai-katsu.jp/articles/marketing-aggregation-ai-suggestion - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-25T00:00:00+00:00 - Tools: Google Analytics 4, Microsoft Clarity, Google Ads, MCP - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: マーケティング > GA4・Clarity・Google広告のデータを自動集計し、AIが改善の兆しや異常値を提案する仕組みを構築しました。リフレッシュトークンによるOAuth認証の完全自動化でアクセストークンの1時間制限を突破。ローカルMCP経由でプロンプト一つで最新数値を取得し、その場で改善策を議論できる環境が整った記録です。 GA4、Clarity、Google広告のデータを自動集計するところまでは、多くの企業が到達します。その次に欲しくなるのは、**人が分析する前にAIが「改善の兆し」や「異常値」を教えてくれる**状態です。 この仕組みを構築し、安定稼働に入りました。特に大きかったのは、**ローカルMCPを介して、プロンプト一つで最新の広告数値を取得し、その場でAIと改善策を議論できる環境**が整ったことです。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月〜11月（10/25〜11/7） | | 使用ツール | GA4 API / Clarity API / Google Ads API / Python（MCP）/ GAS | | やりたかったこと | 散らばったデータを自動集計し、人間が分析する前にAIが改善の兆しや異常値を提案する仕組みを完成させる | | 達成できたこと | **アクセストークンの自動更新による1時間制限の突破**／Clarity・GA4のDiscord通知の安定運用 | | 環境面の成果 | **ローカルMCP経由で、プロンプト一つで最新の広告数値を取得しAIと議論できる環境** | | 状況 | 安定稼働・週次提案ロジック実装中 | > 本記事は自社での検証記録です。広告ROIの改善幅などの定量測定は行っていないため、数値は掲載していません。 ## 結論：数字を「取りに行く」から「聞けば出る」へ この構築で最も体験が変わったのがここです。 **ローカルMCPを介して、プロンプト一つで最新の広告数値を取得し、その場でAIと改善策を議論できる環境を構築しました。** 従来は、数字を確認する作業と、それをもとに考える作業が分断されていました。ダッシュボードを開いて、数字を控えて、別の場所で考える。この往復が思考を止めます。 **「この数字どう思う？」と聞ける状態になると、確認と検討が一続きになります。**レポートを作ってから議論するのではなく、議論しながら必要な数字を取りにいく形に変わりました。 ## 技術的な到達点：1時間制限の突破 この構築の土台になったのが、認証の自動化です。 **リフレッシュトークンを用いたOAuth認証の完全自動化により、アクセストークンの1時間制限を突破しました。** Google系のAPIは、アクセストークンの有効期限が1時間です。定期実行の仕組みでは、これが必ず問題になります。ここを自動化できないと、**「動くけれど、しばらくすると止まっている」という状態から抜け出せません。** 認証の永続化は地味な作業ですが、**ここが片付かないと自動化そのものが成立しません。** ## 環境整備で潰した問題 - **Python実行環境（Pydantic関連）の不具合解消** — MCPを動かすための土台 - **ローカルMCP環境の共有** — 個人の手元だけで動く状態からの脱却 - **リモート環境への移行調査** — ローカル依存を減らすための次段階 ローカルMCPは手軽に始められますが、**「その人のPCでしか動かない」状態のままでは組織の仕組みになりません。**共有と移行の調査を並行して進めているのはそのためです。 ## 次のフェーズ：週次の提案ロジック 現在は**週次提案ロジックの実装中**です。 データが自動で集まり、必要なときに聞ける状態はできました。次は**聞かなくても提案が届く**状態を目指しています。「今週このキーワードの効率が落ちています」といった気づきが、こちらから探しにいかなくても上がってくる形です。 分析業務のルーチン化を解除するには、**人が定期的に見に行く前提そのものを外す必要があります。** ## よくある質問 ### アクセストークンの1時間制限はどう解決しましたか？ **リフレッシュトークンを用いたOAuth認証の完全自動化により突破しました。**Google系APIの定期実行では必ず問題になる箇所で、ここが片付かないと自動化が成立しません。 ### ローカルMCPとは何ですか？ 手元の環境で動かすMCPサーバーのことです。**プロンプト一つで最新の広告数値を取得し、その場でAIと改善策を議論できます。**ただし「その人のPCでしか動かない」状態を脱するため、リモート環境への移行を調査中です。 ### AIが自動で改善提案をしてくれますか？ **現在は週次提案ロジックの実装中です。**データの自動集計と、聞けば答えてくれる環境までは完成しています。聞かなくても提案が届く状態が次の目標です。 ### 広告ROIはどのくらい改善しましたか？ **この検証では定量測定を行っていないため、数値はお答えできません。**環境の構築と安定稼働の確認までの段階です。 ## まとめ - **ローカルMCP経由で、プロンプト一つで広告数値を取得しAIと議論できる環境**を構築 - 数字の確認と検討が分断されていた状態から、**一続きの作業に変わった** - 土台は**リフレッシュトークンによるOAuth認証の完全自動化**。1時間制限を突破した - ローカルMCPは手軽だが**「その人のPCでしか動かない」ままでは組織の仕組みにならない**。共有と移行を並行して進める - 次は**聞かなくても提案が届く**週次ロジックの実装 データ活用の障壁は、データがないことより「見に行くのが面倒なこと」にあります。確認までの手数を削ると、使われ方が変わります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Difyで書類選考を自動化する｜AIが「一般的な優秀さ」で判定してしまう問題への対処 - URL: https://ai-katsu.jp/articles/recruit-agent-dify-build - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-25T00:00:00+00:00 - Models: Gemini - Tools: Dify - Tasks: ナレッジ活用・RAG, 業務プロジェクト - Domain: 採用・人事 > Difyで選考ワークフローを構築し、履歴書・職務経歴書から項目別評価を出力するプロトタイプを作りました。5つの評価項目に重み付けしたスコアリングを実装した一方、求人軸に沿わない「一般的な優秀さ」で判定される問題が判明。詳細な事業・会社情報を前提として注入する必要性をまとめています。 書類選考は、担当者によって基準がぶれやすい作業です。同じ職務経歴書でも、見る人が変われば評価が変わる。そして応募が増えるほど、スクリーニングに時間を取られます。 Difyで選考ワークフローを構築し、**履歴書・職務経歴書をインプットすると項目別に評価が出力されるプロトタイプ**を作りました。動かしてみて分かったのは、**AIは放っておくと「一般的な優秀さ」で判定してしまう**という問題です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月〜11月（10/25〜11/7） | | 使用ツール | Dify / Gemini 1.5 Pro・Flash | | やりたかったこと | 書類選考の属人化を排除し、初期スクリーニングを高速化する | | 作ったもの | Difyによる選考ワークフロー。**5つの評価項目に重み付けを行ったスコアリングロジック** | | 最大の課題 | **特定の求人軸に沿わない「一般的な優秀さ」で判定されてしまう** | | 状況 | 進行中（スコアリングロジック微調整） | > 本記事は自社での検証記録です。スクリーニング工数の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：AIは「その求人にとっての優秀さ」を知らない この検証で最も重要な発見がこれです。 **求人のターゲットによって、AIの評価基準がブレやすいことが分かりました。**たとえばバックオフィス職とAI講師職では、求める人物像がまったく違います。 それにもかかわらず、AIは**特定の求人軸に沿わない「一般的な優秀さ」で判定してしまいます。**学歴が高い、経歴が華やかといった汎用的な指標に引っ張られるのです。 しかし採用の現場では、「優秀だが、この職種には合わない」という判断が日常的に発生します。ここを間違えると、**スクリーニングとして機能しません。** ### 対策：事業と会社の情報を前提として注入する 対応として必要になるのが、**前提情報として詳細な事業・会社情報を注入すること**です。 どんな事業をしていて、その職種が何を担い、どんな人が活躍しているのか。**この文脈がないと、AIは一般論で評価します。**評価基準を職種ごとに具体化して渡す必要があります。 ## スコアリングの設計 プロトタイプでは、**5つの評価項目に対して重み付けを行うスコアリングロジック**を実装しました。 あわせて検討しているのが、**評価項目を星1〜5で可視化する仕組み**です。合計点に応じて星の数を決めます（例：9〜10点で星5）。 | 設計 | 狙い | | --- | --- | | 5項目への重み付け | 職種ごとに重視する軸を変えられる | | 星による可視化 | 数値より直感的に判定できる | **点数のままだと解釈が人によって変わるため、星に丸めることで判断の速度を上げる**という設計です。 ## この取り組みを始めた背景 もともとはIndeed APIを使った応募者情報の自動取得を検討していましたが、**パートナー申請が停滞していました。** そこで、**API連携を待たずに工数削減を先行させる**という判断で、この選考ワークフローの構築に着手しています。応募者情報の取得が手動でも、評価の部分だけ自動化すれば効果は出るためです。 **外部要因で止まっている部分を待たず、自社で完結する範囲から着手する**という進め方です。 ## 今後の展望 この基盤は、次の段階を見据えて作っています。 - **2次選考・最終選考へのエスカレーション** - **面接動画の解析** 書類選考の自動化は入口であり、**選考プロセス全体をデータで繋ぐための土台**という位置づけです。 ## よくある質問 ### AIの評価はそのまま使えますか？ **前提情報を十分に与えないと、求人軸に沿わない「一般的な優秀さ」で判定されます。**事業内容や職種の詳細を前提として注入したうえで、初期スクリーニングの参考にする位置づけが現実的です。 ### なぜ求人ごとに評価がブレるのですか？ **AIは「その求人にとっての優秀さ」を知らないためです。**バックオフィスとAI講師では求める人物像が違いますが、文脈がなければ汎用的な指標で評価してしまいます。 ### 点数ではなく星を使うのはなぜですか？ **点数のままだと解釈が人によって変わるためです。**合計点に応じた星の数（例：9〜10点で星5）に丸めることで、直感的に判定できる形を目指しています。 ### Indeedとの連携はどうなりましたか？ **API利用が停滞していたため、そこを待たずに評価部分の自動化を先行させました。**応募者情報の取得が手動でも、スクリーニングの工数は削減できます。 ## まとめ - Difyで選考ワークフローを構築し、**項目別評価を出力するプロトタイプが完成** - **5つの評価項目に重み付けしたスコアリング**と、星1〜5による可視化を設計 - 最大の課題は**「一般的な優秀さ」で判定されてしまうこと**。求人軸に沿わない評価になる - 対策は**詳細な事業・会社情報を前提として注入すること**。文脈がないとAIは一般論で評価する - Indeed連携の停滞を待たず、**自社で完結する範囲から着手**した AIに評価を任せるとき、判断基準は自分たちで定義して渡す必要があります。「優秀な人を選んで」では、自社にとっての優秀さは伝わりません。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の採用業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 商談の勝ちパターンをデータで探す｜要約ではなく「クロージングへの反応」を抽出する - URL: https://ai-katsu.jp/articles/sales-retrospective-success-analysis - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-25T00:00:00+00:00 - Models: Gemini - Tools: Zoom, Google Apps Script - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: 営業 > Zoom商談の文字起こしから、成約に結びつく勝ちパターンを分析する仕組みを構築中です。単なる要約ではなく、クロージング質問に対する相手の具体的な返答を抽出することで次のアプローチが明確になります。デモの有無や事例説明の有無を項目化し、成約率との相関を可視化する設計をまとめています。 商談の文字起こしを保存するところまでは、多くの企業がやっています。しかし溜めただけでは、営業スキルの標準化には繋がりません。 この検証では、蓄積したデータから**成約に結びつく「勝ちパターン」——ヒアリングの質、質問の回数、デモの有無**を抽出し、成約率との相関を可視化する準備を進めました。単なる要約では届かない部分に踏み込んでいます。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月〜11月（10/25〜11/7） | | 使用ツール | Zoom API / GAS / Gemini API | | やりたかったこと | 成約に結びつく勝ちパターンを定量・定性的に分析し、営業スキルを標準化する | | できたこと | **リスト記入漏れのアラート通知の仕組み化が完了** | | 設計した抽出項目 | ヒアリング時間、質問内容の密度、クロージングフレーズへの相手の反応 | | 状況 | 運用監視および高度分析ロジック構築中 | > 本記事は自社での検証記録です。成約率の変化などの測定は行っていないため、数値は掲載していません。 ## 結論：要約ではなく「相手の反応」を抽出する この検証で最も本質的だった発見がこれです。 **単なる要約ではなく、「受講しますか？」というクロージング質問に対する相手の具体的な返答をピンポイントで抽出する**——これによって、次のアプローチが明確になります。 商談の要約を読んでも、「話は進んだが決まらなかった」以上のことは分かりません。しかし**クロージングでの相手の言葉には、心理的なハードルがそのまま現れます。** 「予算が」なのか「タイミングが」なのか「社内の承認が」なのか。**断り文句の中身が分かれば、次に何を用意すべきかが決まります。** 要約は「何が起きたか」を伝えますが、**抽出は「次に何をすべきか」を教えてくれます。**ここが設計の分かれ目でした。 ## 抽出する項目の設計 プロンプトで抽出する対象として、次を定義しています。 | 項目 | 意図 | | --- | --- | | ヒアリング時間 | 相手の話をどれだけ聞けたか | | 質問内容の密度 | 踏み込んだ質問ができているか | | クロージングへの反応 | 心理的ハードルの正体 | | 実演（デモ）の有無 | 成約率との相関を測る | | 活用事例の説明有無 | 同上 | **「デモをやったかどうか」「事例を出したかどうか」を項目として記録することで、成約率との相関を可視化する準備が整いました。**感覚的に語られていた「デモは効く」を、データで確かめられる状態にするということです。 ## タグ分類による相関分析 成約率との相関を測るため、**商談のタグ分類を定義しました。**「業務-Dify」「副業-画像生成」といった形で、案件の性質を分類します。 営業の勝ちパターンは、扱う商材やターゲットによって変わります。**全体を平均して見ても意味がないため、タグで切り分けたうえで比較する**という設計です。 ## 先に片付けた課題：リストの記入漏れ 分析の前段として、**リスト記入漏れに関するアラート通知機能を実装し、仕組み化が完了しています。** これは地味ですが重要です。**入力されていないデータは分析できません。**どれだけ優れた分析ロジックを作っても、元データに欠けがあれば結論が歪みます。 「分析の前に、データが揃う仕組みを作る」という順序を守ったことが、この取り組みでは効いています。 ## よくある質問 ### 要約だけでは足りないのですか？ **足りません。**要約は「何が起きたか」を伝えますが、次のアクションには繋がりません。クロージング質問に対する相手の具体的な返答を抽出することで、心理的ハードルの正体が見えます。 ### どんな項目を分析していますか？ ヒアリング時間、質問内容の密度、クロージングへの反応に加え、**実演（デモ）の有無や活用事例の説明有無**を項目化しています。成約率との相関を測るためです。 ### なぜタグ分類が必要なのですか？ **商材やターゲットによって勝ちパターンが変わるためです。**全体を平均して見ても意味がないため、「業務-Dify」「副業-画像生成」といったタグで切り分けて比較します。 ### 成約率は改善しましたか？ **現在は分析ロジックの構築中で、成約率の変化は測定していません。**相関を可視化する準備が整った段階です。 ## まとめ - **要約ではなく、クロージング質問への相手の具体的な返答を抽出する**ことで、次のアプローチが明確になる - ヒアリング時間・質問密度・**デモの有無・事例説明の有無**を項目化し、成約率との相関を測る準備が完了 - 商材ごとに勝ちパターンが違うため、**タグ分類で切り分けて比較**する設計 - 分析の前に**リスト記入漏れのアラート通知**を実装。入力されていないデータは分析できない 営業データの活用では、記録を増やすことより「何を抽出するか」の設計が成果を分けます。溜めるだけでは、読み返されずに終わります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の営業DXとAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## SNSの自律投稿で質を担保する｜新着順をやめてエンゲージメント基準に変えた理由 - URL: https://ai-katsu.jp/articles/x-techjii-bcrew-ai-news - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-25T00:00:00+00:00 - Tools: X（旧Twitter） - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: マーケティング > X APIで有益なAI情報の収集と発信を自動化する仕組みを構築しました。6時間間隔でリストを取得し、独自のエンゲージメント計算ロジックで上位5件を抽出・タグ付けする構成です。新着順では情報の質が担保できないという課題と、「すべて流さない」設計が選別を機能させる理由をまとめています。 SNSでの情報発信を自動化するとき、多くの仕組みは「新着順」で投稿を選びます。実装は簡単ですが、これでは**情報の質を担保できません。**新しいだけで価値の薄い投稿が流れてしまいます。 この検証では、**エンゲージメントに基づいたフィルタリングを組み込むことで、自律投稿の質を保つ仕組み**を構築しました。6時間ごとに収集し、独自ロジックで上位5件を抽出します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月〜11月（10/25〜11/7） | | 使用ツール | X API | | やりたかったこと | 有益なAI情報の収集と発信を自動化し、SNSでのプレゼンス向上とコミュニティへの価値還元を最大化する | | 構築したもの | **6時間間隔でXのリストを取得し、独自のエンゲージメント計算ロジックで上位5件を抽出・タグ付け** | | 結論 | **新着順ではなくエンゲージメントに基づくフィルタリングにより、情報の質を担保した自律投稿が可能** | | 状況 | 構築完了・運用フェーズ移行中 | > 本記事は自社での検証記録です。フォロワー数やインプレッションの変化などの測定は行っていないため、数値は掲載していません。 ## 結論：新着順では質が担保できない この検証で確立した設計方針がこれです。 **単なる「新着順」ではなく、エンゲージメントに基づいたフィルタリングを行うことで、情報の質を担保した自律投稿が可能になります。** 新着順は実装が単純ですが、選別が行われません。結果として、**「新しいだけの情報」がそのまま流れます。**これを続けると、アカウントの信頼が下がります。 一方、エンゲージメントを指標にすると、**すでに他の人が価値を認めた投稿**が上がってきます。人間が「これは良い」と判断した結果を、選別の基準として借りる形です。 ## 仕組みの構成 ``` 6時間間隔で X のリストを取得 ↓ 独自ロジック（エンゲージメント計算）で評価 ↓ 上位5件を抽出 ↓ タグ付けして出力 ``` 設計で意図的に絞っている点が2つあります。 - **6時間間隔** — 常時監視ではなく、まとまった単位で処理する - **上位5件** — 量ではなく質で絞る **取得できる情報をすべて流すのではなく、明確に上限を設けることが質の担保に繋がります。**5件という制限があるからこそ、選別ロジックが意味を持ちます。 ## タグ付けの役割 抽出した投稿にはタグを付けています。これにより、**後から「どの領域の情報が多かったか」を振り返れる**ようになります。 発信のための仕組みですが、**タグ付きで蓄積されることで、社内のインプット資産にもなります。**収集した情報が一度流れて消えるのではなく、分類された状態で残る構成です。 ## よくある質問 ### なぜ新着順ではダメなのですか？ **選別が行われないためです。**新しいだけで価値の薄い投稿がそのまま流れ、アカウントの信頼を下げます。エンゲージメントを指標にすると、すでに他の人が価値を認めた投稿を選べます。 ### なぜ6時間間隔なのですか？ 常時監視ではなく、まとまった単位で処理するためです。**一定の期間で溜まった投稿を比較することで、エンゲージメントによる選別が機能します。** ### なぜ5件に絞るのですか？ **量ではなく質で絞るためです。**取得できる情報をすべて流すと選別の意味がなくなります。明確な上限があるからこそ、ロジックが働きます。 ### 収集した情報は発信だけに使うのですか？ **タグ付きで蓄積されるため、社内のインプット資産にもなります。**一度流れて消えるのではなく、分類された状態で残る設計です。 ## まとめ - **6時間間隔でXのリストを取得し、独自のエンゲージメント計算ロジックで上位5件を抽出**する仕組みを構築 - **新着順ではなくエンゲージメント基準にすることで、情報の質を担保した自律投稿が可能**になる - 「すべて流す」のではなく**明確な上限（5件）を設ける**ことが、選別ロジックを機能させる - タグ付けにより、収集した情報が**社内のインプット資産としても残る** 自動投稿の設計では、何を投稿するかより「何を投稿しないか」を決めるほうが質に効きます。フィルタが甘いと、自動化はそのままノイズの量産になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## X APIでAI情報の収集と発信を自動化する｜キャラクターの口調はプロンプトで再現できる - URL: https://ai-katsu.jp/articles/x-techjii-ai-info-notify - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-13T00:00:00+00:00 - Tools: X（旧Twitter）, n8n, Google Apps Script - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: マーケティング > X（旧Twitter）のAPIとn8nを使い、最新AI情報の収集から要約・投稿までを自動化する仕組みを構築中です。自社キャラクターの語り口をプロンプトで再現できることを確認した一方、無料枠の制約内で情報密度を上げるフィルタリング手法が課題に。発信と社内知見のアップデートを両立させる設計をまとめています。 AI領域の情報は流れが速く、手動で追い続けるには限界があります。同時に、集めた情報を発信し続けるのも手間がかかります。 この2つをまとめて自動化するため、**X（旧Twitter）のAPIを使って情報収集から要約、投稿までを繋ぐ仕組み**を構築中です。自社キャラクター「テクじい」の口調を再現するプロンプトの有効性も確認できました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月（10/13〜10/24） | | 使用ツール | X API / n8n / GAS | | やりたかったこと | X上での最新AI情報の収集・要約・投稿を自動化し、認知拡大と社内知見のアップデートを両立する | | できたこと | キーワードによる情報取得からDiscord通知までの**基盤設計**／キャラクター口調を再現するプロンプトの有効性確認 | | 課題 | **X APIの無料枠の制約内で、収集する情報の密度を上げるフィルタリング手法が必要** | | 状況 | 構築中 | > 本記事は自社での検証記録です。フォロワー数やエンゲージメントの変化などの測定は行っていないため、数値は掲載していません。 ## 結論：口調の再現はプロンプトで足りる この検証で確認できたことのひとつがこれです。 **キャラクター特有の「語り口」を再現するプロンプトの有効性を確認しました。**収集した情報を、そのアカウントらしい話し方に変換して出力できます。 自動投稿でありがちなのは、情報は正しいが文体が無機質で、アカウントの個性が消えてしまうことです。**収集と要約を自動化しても、出力の口調さえ固定できれば、発信の一貫性は保てます。** ファインチューニングのような重い手段を使わずとも、プロンプト設計で十分に成立するという確認ができました。 ## 構成 ``` X API（特定キーワードのポストを自動収集） ↓ n8n LLM で要約 ＋ キャラクター口調へ変換 ↓ Discord へ通知 ／ 投稿 ``` 現時点では**情報取得からDiscord通知までの基盤設計**が完了しています。あわせて、伸びている投稿の傾向を特定するインサイト分析のロジックも検討中です。 ## 課題：無料枠の中で情報の密度をどう上げるか 実装上の制約として、これが効いています。 **X APIの無料枠には制約があるため、その範囲内で収集する情報の密度を上げるフィルタリング手法が必要です。** 取得できる回数や件数に上限がある以上、**「たくさん取る」方向では詰まります。**限られた取得枠で、いかに有益なポストだけを拾うか——設計の重心はフィルタリングに移ります。 キーワードの選び方、除外条件、取得タイミング。**制約があるほど、何を捨てるかの設計が重要になります。** ## この仕組みの二重の狙い この自動化は、発信だけを目的にしたものではありません。 | 狙い | 内容 | | --- | --- | | **対外** | アカウントの自律的な投稿による認知拡大 | | **対内** | 有益なポストの自動収集による社内知見のアップデート | **集めた情報は発信に使うだけでなく、そのまま社内のインプットにもなります。**Discordに流れる時点で、チーム全員が最新情報に触れられる状態になります。 1つの仕組みで内外両方に効く構成にできると、運用の労力に対する見返りが大きくなります。 ## よくある質問 ### キャラクターの口調は再現できますか？ **プロンプト設計で再現できることを確認しました。**収集した情報を、そのアカウントらしい語り口に変換して出力できます。ファインチューニングのような重い手段は使っていません。 ### X APIの無料枠で足りますか？ **制約があるため、収集する情報の密度を上げるフィルタリング手法が必要です。**取得回数や件数に上限がある以上、「たくさん取る」のではなく「有益なものだけ拾う」設計が求められます。 ### 完全に自動で投稿されるのですか？ **現時点では情報取得からDiscord通知までの基盤設計が完了した段階です。**投稿までの完全自動化と、インサイト分析のロジックは構築中です。 ## まとめ - X APIとn8nで、**最新AI情報の収集からDiscord通知までの基盤を設計** - **キャラクター特有の語り口はプロンプトで再現できる**ことを確認 - 課題は**無料枠の制約内で情報の密度を上げるフィルタリング**。「たくさん取る」方向では詰まる - この仕組みは**対外的な発信と、社内知見のアップデートの両方**に効く SNS運用の自動化では、投稿を自動化するだけでなく「集めた情報が社内にも流れる」構造にすると、投資に対する見返りが大きくなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AI研修の教材を量産する｜DifyのDSLファイルで課題を複製し、Guardrailsで安全性を担保する - URL: https://ai-katsu.jp/articles/training-knowledge-dify-bedrock - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-11T00:00:00+00:00 - Models: AWS Bedrock, OpenAI Codex - Tools: Dify - Tasks: ナレッジ活用・RAG, ツール検証 - Domain: 教育・研修 > ビジネス研修と社内エンジニア教育向けに、DifyとAWS Bedrockの活用法を体系化しました。DifyのエクスポートファイルであるDSLを使うことで初級から中級者向けのワークフロー課題を瞬時に複製・提供でき、教育効率が大幅に向上。あわせてGuardrailsで安全なAI利用の範囲を環境側に定義した記録です。 AI研修で難しいのは、受講者のレベルに合わせた課題を用意することです。初級者向けと中級者向けでは求める内容が違い、毎回ゼロから作っていては講師側の負担が積み上がります。 この検証では、**DifyのDSLファイル（エクスポート形式）を使って、ワークフロー課題を瞬時に複製・提供できるスキーム**を構築しました。あわせてGuardrailsによる安全なAI利用の定義も行っています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月（10/11〜10/17） | | 使用ツール | Dify / AWS Bedrock / OpenAI Codex | | やりたかったこと | ビジネス研修および社内エンジニア教育用として、DifyやAWS Bedrockの活用法を体系化する | | 構築したもの | **Dify DSLファイルによる課題量産スキーム**／**DifyへのGuardrails適用** | | 効果 | 初級から中級者向けのワークフロー課題を瞬時に複製・提供でき、教育効率が大幅に向上 | | 判定 | 完了（教材化準備完了） | > 本記事は自社での検証記録です。教材作成時間の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：DSLファイルが課題のテンプレートになる この検証で最も効果が大きかったのがこれです。 **DifyのエクスポートファイルであるDSLを活用すると、初級から中級者向けのワークフロー課題を瞬時に複製・提供できます。**結果として、教育効率が大幅に向上しました。 研修では「講師が作った完成形」と「受講者が作りかけの状態」の両方が必要になります。DSLでやりとりできると、**この2つを同じ形式で配布・回収できます。** 課題を1つ作れば、そこから派生させて難易度の違う複数のバリエーションを用意できる。**教材づくりの単位が「1つずつ手で作るもの」から「テンプレートから量産するもの」に変わります。** ## Guardrailsで安全なAI利用を定義する 研修用途で見逃せないのが、この部分です。 **DifyにGuardrailsを適用し、安全なAI利用の範囲を定義しました。** 受講者が自由にAIを触る環境では、意図しない入力や出力が起こり得ます。研修の場だからこそ、**「やってはいけないこと」を仕組みとして持たせておく必要があります。** ルールを口頭で伝えるだけでは守られません。Guardrailsのように**環境側で制約をかけておくほうが、教える側の負担も減ります。** ## 組み合わせたツール | ツール | 役割 | | --- | --- | | Dify | ワークフロー課題の作成・配布（DSL）、Guardrailsの適用 | | AWS Bedrock | セキュリティ要件を踏まえたモデル利用 | | OpenAI Codex | 教材づくりの補助 | 企業研修では、**受講者の入力がどこに送られるかが問われる**ことがあります。AWS Bedrockを選択肢に含めているのは、その要件に応えるためです。 ## 研修設計への示唆 今回の検証から、AI研修を設計する際のポイントを整理します。 - **課題は複製できる形式で作る** — 手作りでは受講者数に対してスケールしない - **安全な範囲は環境側で定義する** — 口頭のルールでは守られない - **難易度のバリエーションを前提にする** — 初級と中級で必要な内容は違う ## よくある質問 ### DSLファイルとは何ですか？ **Difyのワークフローをエクスポートした形式のファイルです。**これをやりとりすることで、作成したワークフローを別の環境に複製できます。研修では課題の配布・回収に使えます。 ### なぜAWS Bedrockを使うのですか？ **セキュリティ要件を踏まえた選択肢として組み込んでいます。**企業研修では受講者の入力がどこへ送られるかが問われることがあり、その要件に応えるためです。 ### Guardrailsは何のために設定するのですか？ **受講者が自由にAIを触る環境で、安全な利用範囲を仕組みとして定義するためです。**ルールを口頭で伝えるだけでは守られないため、環境側で制約をかけています。 ### どのくらい教材作成が楽になりましたか？ **この検証では定量測定を行っていないため、数値はお答えできません。**「課題を瞬時に複製・提供でき、教育効率が大幅に向上した」という定性的な評価です。 ## まとめ - **DifyのDSLファイルを使うと、ワークフロー課題を瞬時に複製・提供できる**。教材づくりが量産可能になる - **Guardrailsを適用**し、受講者が安全にAIを触れる範囲を環境側で定義した - AWS Bedrockを組み合わせ、セキュリティ要件を踏まえた構成に - 研修設計では**「複製できる形式」「環境側での制約」「難易度のバリエーション」**を前提にする AI研修は内容そのものより、教材を回し続けられる仕組みがあるかで持続性が決まります。今回はその土台を作った検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のリスキリングとAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 1時間で切れるトークンをどう扱うか｜マーケ指標の自動通知で越えたOAuthの壁 - URL: https://ai-katsu.jp/articles/marketing-kpi-ga4-clarity-ads - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-11T00:00:00+00:00 - Tools: Google Apps Script, MCP, Vercel, Google Analytics 4, Microsoft Clarity - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: マーケティング > GA4・Clarity・Google広告の指標を自動集計しDiscordへ通知する環境を構築しました。最大の障壁はGoogle認証のアクセストークンが1時間で期限切れになること。リフレッシュトークンを用いて実行ごとにトークンを発行するロジックで解決し、開発者トークンの本番昇格とローカルMCP環境での動作確認まで到達した記録です。 GA4、Clarity、Google広告。それぞれを個別に開いて確認する時間は、積み重なると無視できません。指標の見落としも起きます。 これらを自動集計し、AIによる改善提案までワンストップで受け取る環境を構築しました。特に苦労したのが**Google認証の有効期限**です。アクセストークンは1時間で切れます。この自動更新処理を確立できたことが、今回の実質的な成果でした。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月（10/11〜10/24） | | 使用ツール | GAS / ローカルMCP / Vercel / GA4 / Clarity / Google Ads | | やりたかったこと | 複数の分析ツールを個別確認する工数を削減し、AIによる自動集計と改善提案をワンストップで受け取る | | 達成できたこと | GA4・ClarityのDiscord自動通知の成功／開発者トークンの本番昇格／ローカルMCP環境での動作確認完了 | | 技術的な成果 | **1時間で期限が切れるアクセストークンの自動更新処理を確立** | | 状況 | 進行中（環境整備完了、パラメータ選定フェーズ） | > 本記事は自社での検証記録です。工数削減の定量測定は行っていないため、数値は掲載していません。 ## 結論：1時間で切れるトークンをどう扱うか この構築で最大の技術的課題がこれでした。 **Google認証（OAuth）のアクセストークンは1時間で期限が切れます。**定期実行の仕組みでは、これが致命的になります。夜間に走らせた処理が認証切れで止まっていた、という事態が起きるからです。 解決策として採用したのが、**リフレッシュトークンを用いて、実行のたびにアクセストークンを発行するロジック**です。トークンを保存して使い回すのではなく、必要になった時点で取り直します。 **この自動更新処理を確立できたことが、環境整備における実質的な到達点でした。** ## 構成 ``` GAS / ローカルMCP / Vercel ↓ リフレッシュトークンでアクセストークンを都度発行 GA4 / Clarity / Google Ads API ↓ Discord へ自動通知 ``` 実行環境をGAS・ローカルMCP・Vercelに分けているのは、**処理の性質に応じて置き場所を変えるため**です。すべてを1つに寄せず、認証まわりの安定性が要る部分を切り出しています。 ## 達成できたこと - **GA4・ClarityのDiscord自動通知が成功** — 指標の巡回作業が減る - **開発者トークンの本番昇格** — 実データを扱うための前提をクリア - **ローカルMCP環境での動作確認完了** — 手元でデータを取れる状態に 以前の検証では、リモート環境での認証維持が煩雑だという課題が出ていました。**ローカルMCPという選択肢を含めた構成に切り替えたことで、この部分が前進しています。** ## 現在のフェーズ：何を通知するかを選ぶ 環境整備が完了し、現在は**パラメータ選定フェーズ**にあります。 データを取れるようになったあとに残るのは、**「どの指標を、どの頻度で通知するか」という設計の問題**です。全部を毎日流すと、通知そのものが読まれなくなります。 自動通知の仕組みは、作った時点では完成しません。**受け取る側が反応できる量に絞り込むところまでが設計に含まれます。** ## よくある質問 ### アクセストークンが1時間で切れる問題はどう解決しましたか？ **リフレッシュトークンを用いて、実行のたびにアクセストークンを発行するロジックを採用しました。**トークンを保存して使い回すのではなく、必要な時点で取り直す方式です。 ### なぜ実行環境を複数使っているのですか？ **処理の性質に応じて置き場所を変えるためです。**GAS・ローカルMCP・Vercelを組み合わせ、認証まわりの安定性が求められる部分を切り出しています。 ### すでに運用に乗っていますか？ **環境整備は完了し、GA4・ClarityのDiscord自動通知は成功しています。**現在は「どの指標をどの頻度で通知するか」を決めるパラメータ選定のフェーズです。 ### どのくらい工数が減りましたか？ **この検証では定量測定を行っていないため、数値はお答えできません。** ## まとめ - **Google認証のアクセストークンは1時間で切れる。**定期実行の仕組みではここが最大の障壁になる - 解決策は**リフレッシュトークンによる、実行ごとのアクセストークン発行** - GA4・ClarityのDiscord自動通知に成功。開発者トークンの本番昇格も完了 - 環境整備の完了後に残るのは**「何を、どの頻度で通知するか」の設計**。全部流すと読まれなくなる 定期実行の自動化は、作るところより「止まらずに動き続けること」が難しい領域です。認証の期限をどう扱うかは、最初に設計しておくべき項目になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Indeed連携は技術より契約が壁になる｜応募者スコアリング自動化で判明した4つの前提 - URL: https://ai-katsu.jp/articles/indeed-api-applicant-scoring - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-11T00:00:00+00:00 - Tools: Indeed API - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: 採用・人事 > Indeedのエントリー情報を自動取得し候補者をスコアリングする仕組みを検討しました。調査の結果、実運用にはIndeedデベロッパー契約が必須で、XMLフィードの配置も必要。さらに既存ATSのAPI対応状況の確認も欠かせません。パートナー申請が停滞している現状と、着手前に揃えるべき条件を整理しています。 応募者へのレスポンス速度と、選考基準の平準化。この2つを同時に解決するために、Indeedのエントリー情報を自動取得して候補者をスコアリングする仕組みを検討しました。 現在は**Indeedへのパートナー申請が停滞しており、督促中**という段階です。実装に入る前の調査で分かった技術要件と、実運用に向けて必要になる契約面の条件を記録として残します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月（10/11〜10/24） | | 使用ツール | Indeed Apply API | | やりたかったこと | Indeedのエントリー情報を自動取得し、定義した基準で候補者をスコアリングして初期選考を自動化する | | 進んだところ | API利用可否の一次調査完了、パートナー申請の実行、問い合わせ（督促）の実施 | | 技術要件 | **Indeed側へ送信するXMLフィードの配置が必要** | | 契約要件 | **実運用にはIndeedデベロッパー契約が必須** | | 状況 | 調査・申請停滞（督促中） | > 本記事は自社での検証記録です。実装に至っていないため、効果の数値はありません。調査で判明した要件の記録です。 ## 結論：実装より先に、契約と申請が壁になる この検討で明確になったのは、**技術的な難易度より手続きのほうが先に来る**ということです。 整理すると、着手までに次の条件を満たす必要があります。 1. **Indeedデベロッパー契約** — 実運用には必須 2. **パートナー申請の承認** — 今回はここで停滞している 3. **XMLフィードの配置** — Indeed側へ求人情報を送るための仕組み 4. **既存ATSのAPI対応状況の確認** — 干渉が起きないか **コードを書き始める前に、この4つが揃うかを見極める必要があります。**逆に言えば、ここが揃わない限り着手しても動きません。 ## 技術要件：APIだけでは繋がらない 調査で明確にできた技術的な条件です。 **Indeed側へ送信するための「XMLフィード」の配置が必要です。**応募者情報を受け取るAPIだけでなく、求人情報を渡す仕組みも用意する必要があります。 APIキーを取得すれば繋がる、という構成ではありません。**双方向の連携を前提に設計する必要があります。** ## 既存ATSとの関係を先に確認する もう一つの重要な確認事項です。 **既存の採用管理システム（ATS）を利用している場合は、そのシステム側のAPI対応状況も併せて確認が必要です。** ATS側もIndeed連携に対応していると、応募データが二重に流れる可能性があります。**効率化のつもりが対応漏れの原因になる**ため、役割分担を先に決めておく必要があります。 ## 個人情報の扱い：PoCと本番で環境を分ける 方針として先に決めたことです。 **機密情報を扱うため、PoC後はVPSやセキュアなiPaaS環境での運用へ移行する**としました。 応募者の氏名・連絡先・職務経歴は、社内でも取り扱いに配慮が要る情報です。検証段階で手軽に動かせることと、本番で預かってよいことは別の基準で判断します。 > **「PoCで動いたからそのまま本番へ」は、個人情報を扱う仕組みでは避けるべき進め方です。**移行先を最初に決めておくと、後から作り直す必要がなくなります。 ## よくある質問 ### なぜ止まっているのですか？ **Indeedへのパートナー申請が停滞しているためです。**現在は問い合わせによる督促を行っている段階です。技術的な障壁ではなく、手続き上の待ちです。 ### Indeed Apply APIを使うのに何が必要ですか？ **実運用にはIndeedデベロッパー契約が必須です。**加えて、Indeed側へ送信するXMLフィードの配置も必要になります。APIキーだけでは完結しません。 ### 既存の採用管理システムがある場合は？ **そのシステム側のAPI対応状況を必ず確認してください。**ATSもIndeed連携に対応していると、応募データが二重に流れて対応漏れを招く恐れがあります。 ### スコアリングの精度はどうでしたか？ **実装に至っていないため、精度の評価はまだできていません。**現時点は仕様調査と申請の段階です。 ## まとめ - Indeed連携は**技術より先に契約・申請が壁になる**。デベロッパー契約とパートナー申請が前提 - APIだけでは完結せず、**XMLフィードの配置が必要** - **既存ATSのAPI対応状況を必ず確認する**。二重取得は対応漏れを招く - 個人情報を扱うため、**PoC後はVPSやセキュアなiPaaS環境へ移行**する方針 外部プラットフォームとの連携では、実現可能性の調査に契約条件まで含めておく必要があります。技術検証だけ進めても、承認が下りなければ動かせません。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の採用業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Zoom商談の要約と文字起こしを自動集約する｜Webhookが取れない制約をどう回避したか - URL: https://ai-katsu.jp/articles/sales-retrospective-gas-zoom - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-11T00:00:00+00:00 - Tools: Zoom, Google Apps Script - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: 営業 > Zoom AIコンパニオンの要約と文字起こしを自動集約し、営業の振り返りコメントを抽出する仕組みを構築しました。文字起こし単体のWebhookが取得できない制約に対し、要約WebhookのUUIDをキーに後追い取得する設計を採用。5万文字超のデータ分割やBot除外など、安定稼働に必要だった実装をまとめています。 商談の記録は「何を話したか（事実）」と「どう感じたか（反省）」の両方が揃って初めて振り返りに使えます。前者はZoom AIコンパニオンが出してくれますが、後者は担当者が書き残さないと残りません。 この2つを自動で集約し、スプレッドシートとDiscordに流す仕組みを構築しました。**安定稼働に入っており、大きな支障が出るエラーは発生していません。**実装で必要になった細かい処理を中心に共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月（10/11〜10/24） | | 使用ツール | Zoom AI Companion / GAS / Discord / スプレッドシート | | やりたかったこと | 要約と文字起こしを自動集約し、営業担当者の「振り返りコメント」を抽出・分析する | | 結論 | スプレッドシートへの自動転記とDiscord通知が**安定稼働**。運用監視で大きな支障となるエラーは未発生 | | 設計の要点 | 文字起こし単体のWebhookが取れないため、**要約Webhook受信時のUUIDをキーに定期実行で後追い取得** | | 状況 | 運用監視・分析ロジック構築中 | > 本記事は自社での検証記録です。報告工数の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 設計上の壁：文字起こしのWebhookが取れない この構築で最初に突き当たった制約です。 **文字起こし単体のWebhookが取得できませんでした。**要約は通知されるのに、文字起こしはその場では受け取れない。イベント駆動で組もうとすると、ここで詰まります。 採用した解決策はこうです。**要約Webhookを受信したタイミングでUUIDを取得し、それをキーにして定期実行で文字起こしを後追いで取りにいく。** ``` Zoom（商談終了） ↓ 要約 Webhook（UUIDを取得） GAS が発火 → UUIDを記録 ↓ 定期実行 UUID をキーに文字起こしを後追い取得 ↓ スプレッドシート転記 ＋ Discord 通知 ``` **イベントで取れないものは、鍵だけ受け取って後から取りに行く。**外部サービスと繋ぐ際によく必要になる考え方です。 ## 実装で必要だった処理 ### 5万文字を超えるデータの分割 商談の文字起こしは非常に長くなります。**スプレッドシートには1セルあたりの文字数制限があるため、そのまま入れると収まりません。** 対応として、**複数のセル（列）にデータを逃がす処理を実装しました。**5万文字を超えるケースを想定した分割処理です。 この点は見落とされがちですが、**長い文字起こしを扱う仕組みでは必ず踏む問題です。**設計時点で分割を前提にしておくと、後から慌てずに済みます。 ### 担当者コメントのトリミング 振り返りコメントを抽出する際、そのまま取ると発言者名などが混ざります。**担当者コメントのトリミング処理**を実装し、読める形に整えています。 ### サービスアカウントの除外 会議には人間以外の参加者も入ります。**Botなどのサービスアカウント名を除外するフィルタリングを実装しました。**これがないと、振り返り分析にノイズが混ざります。 ## 運用状況 **運用監視において、大きな支障が出るエラーは発生していません。**実用レベルでの稼働を確認できています。 現在は分析ロジックの構築段階です。データが溜まる仕組みは動いているので、**次はそこから何を読み取るかというフェーズ**に入っています。 ## よくある質問 ### Zoomの文字起こしはWebhookで取れないのですか？ **文字起こし単体のWebhookは取得できませんでした。**要約Webhookの受信時にUUIDを取得し、それをキーに定期実行で後追い取得する設計にしています。 ### 長い文字起こしはどう扱いますか？ **スプレッドシートの1セル制限を回避するため、複数セル（列）にデータを逃がす処理が必要です。**5万文字を超えるケースを想定した分割処理を実装しています。 ### Botの発言はどう除外していますか？ **サービスアカウント名の除外フィルタリングを実装しています。**会議にはBot等が参加していることがあり、これを含めると分析にノイズが入ります。 ### 安定して動いていますか？ **運用監視において、大きな支障となるエラーは発生していません。**スプレッドシート転記とDiscord通知は実用レベルで稼働しています。 ## まとめ - Zoom AIコンパニオンの要約と文字起こしを集約し、**スプレッドシート転記とDiscord通知が安定稼働** - **文字起こし単体のWebhookが取れない**制約に対し、要約WebhookのUUIDをキーに後追い取得する設計を採用 - **5万文字超のデータは複数セルに分割**する処理が必須 - 担当者コメントのトリミングと、**Botなどサービスアカウントの除外フィルタリング**で分析可能な形に整えた 自動化の実装では、主要な処理よりもこうした細部の後始末が動作の安定性を左右します。データが「入る」ことと「使える形で入る」ことは別問題です。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の営業DXとAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIエージェント同士を連携させる｜A2A Protocolで他エージェントの自動発見を検証 - URL: https://ai-katsu.jp/articles/a2a-agent-communication - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-11T00:00:00+00:00 - Tools: GitHub - Tasks: AIエージェント, ツール検証 > 複数のAIエージェントがHTTPS通信で連携しタスクを完遂する「A2A（Agent to Agent）」を、MastraとA2A Protocolで検証しました。エージェントが利用可能な他エージェントを自動発見し、依頼して成果物を受け取るフローの動作を確認。一方でコンテキスト共有の深度という課題も見えた記録です。 AIエージェントを1つ作って動かすところまでは、多くの企業が到達しています。次の段階は、**役割の違う複数のエージェントが互いに連携して、人が介在せずにタスクを完遂する**という形です。 この「A2A（Agent to Agent）」の実現可能性を、MastraとA2A Protocolで検証しました。結果として、**エージェントが他のエージェントを自動で発見し、依頼して、成果物を受け取る**という一連の流れの動作を確認できています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月（10/11〜10/17） | | 使用ツール | Mastra（A2A Protocol）/ Python / GitHub Codespace | | やりたかったこと | 複数のAIエージェントがHTTPS通信で対話・連携し、人が介在せずタスクを完遂する仕組みの検証 | | 確認できたこと | **他エージェントの自動発見（discovered\_agents）→ メッセージ送信 → 成果物の受け取り**という一連のフロー | | 検証内容 | クライアント側から俳句エージェントを呼び出し、特定テーマ（ゲーム「Strands」）に沿った出力を得る | | 課題 | エージェント間のコンテキスト共有の深度 | | 判定 | 完了（基本動作確認済み） | > 本記事は自社での検証記録です。実業務への適用は行っていないため、効果の数値はありません。 ## 結論：エージェントが他のエージェントを見つけて呼べる この検証で確認できた最も重要な挙動がこれです。 **エージェントが、利用可能な他のエージェントを自動で発見（discovered\_agents）し、メッセージを送信して成果物を受け取る**という一連のフローが動きました。 ポイントは「どのエージェントに頼むか」を人間が指定していない点です。**使える相手を自分で見つけて、依頼する。**これが成立すると、専門特化した小さなエージェントを並べておくだけで、必要な組み合わせが自動的に作られる可能性が出てきます。 今回は俳句を生成する専門エージェントを、クライアント側から呼び出す構成で確認しました。 ## HTTPS通信で繋がることの意味 技術的に見逃せない発見がこれです。 **ローカル環境であっても、HTTPS通信を介したエージェント同士の疎通が確立できれば、将来的に異なるプラットフォームやサーバー間でのAI連携が可能になります。** 同じアプリケーションの中で完結する連携ではなく、**ネットワーク越しに別々のシステムのエージェントが会話する**という構図です。自社のエージェントと取引先のエージェントが直接やりとりする、といった将来像に繋がります。 ## 課題：コンテキスト共有の深度 一方で、明確な課題も見えました。**エージェント間のコンテキスト共有の深度**です。 今回の検証は**単発の呼び出し**でした。「このテーマで俳句を作って」と依頼し、結果を受け取る。この範囲であれば問題ありません。 しかし複雑なタスクになると、**やりとりの途中経過や前提を、エージェント間でどこまで共有するか**という設計が必要になります。何度も往復するタスクでは、**状態（State）を保持するための設計が要る**というのが今回の想定です。 人間のチームでも、都度ゼロから説明していては仕事になりません。**エージェント間の連携でも、同じ問題が形を変えて現れます。** ## 現時点での位置づけ A2Aはまだ実業務に投入する段階ではありませんが、**基本動作が確認できたことには意味があります。** - 専門特化した小さなエージェントを並べる設計が現実味を帯びる - プラットフォームを跨いだAI連携の土台になる - ただし複雑なタスクには状態管理の設計が必要 ## よくある質問 ### A2Aとは何ですか？ **Agent to Agent の略で、AIエージェント同士が直接連携してタスクを完遂する仕組みです。**人間が「次はこのAIに聞いて」と指示するのではなく、エージェントが自分で必要な相手を見つけて依頼します。 ### 実業務で使えますか？ **現時点では基本動作の確認段階です。**単発の呼び出しは問題なく動きましたが、複雑なタスクではエージェント間の状態保持の設計が必要になると想定しています。 ### MCPとは何が違いますか？ MCPはAIと外部ツールを繋ぐ規格ですが、**A2Aはエージェント同士を繋ぐものです。**前者は「AIが道具を使う」、後者は「AIがAIに頼む」という構図の違いがあります。 ### 何が課題として残りましたか？ **エージェント間のコンテキスト共有の深度です。**今回は単発の呼び出しでしたが、複雑なタスクでは状態（State）を保持する設計が必要になります。 ## まとめ - **エージェントが他エージェントを自動発見（discovered\_agents）し、依頼して成果物を受け取る**フローを確認 - 「どのエージェントに頼むか」を人間が指定しない点が、従来の連携との大きな違い - **HTTPS通信で疎通できれば、プラットフォームやサーバーを跨いだAI連携に繋がる** - 課題は**コンテキスト共有の深度**。複雑なタスクには状態保持の設計が必要 AIエージェントの次の段階は、1体を賢くすることではなく、複数体をどう連携させるかに移りつつあります。その入口を確認した検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Google Meetの議事録自動通知を作る｜コードは書けたが権限で止まった記録 - URL: https://ai-katsu.jp/articles/google-meet-minutes-notify - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-07T00:00:00+00:00 - Models: Claude Code - Tools: Google Workspace, Google Apps Script - Tasks: 業務自動化・ワークフロー, ツール検証 > Google Meetの会議終了後に議事録を自動作成しDiscordへ通知する仕組みを、Claude CodeでGASのベースコードまで実装しました。ただしGoogle Workspaceの管理権限とAPI連携設定が未完了で動作確認に進めていません。実装が速くなった今、権限確保をスケジュールに含める必要があるという記録です。 会議が終わったら議事録が自動でできていて、チームのチャットに流れている。Zoomではすでに動かしていた仕組みを、**Google Meet でも同じように実現できないか**という検証です。 コードの実装はClaude Codeで完了しました。ただし現在は**Google Workspace の管理権限とAPI連携の設定待ち**で止まっています。技術ではなく権限が律速になった、という記録です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月7日〜（検証中） | | 使用ツール | Google Meet / Google Apps Script（GAS）/ Discord / Claude Code | | やりたかったこと | Google Meet の会議終了後、自動で議事録を作成しDiscordへ通知する | | できたこと | **Claude Code を用いた GAS ベースコードの実装完了** | | 止まっている理由 | **Google Workspace の管理権限とAPI連携設定が未完了** | | 状況 | 進行中（コード実装完了、API連携待ち） | > 本記事は自社での検証記録です。動作確認まで至っていないため、成果や効果の数値はありません。 ## 結論：コードは書けても、権限がなければ動かない この検証で記録として残す価値があるのは、この一点です。 **Claude CodeでGASのベースコードは実装完了しています。**実装そのものは詰まりませんでした。それでも動作確認に進めていないのは、**Google Workspace の管理権限の取得と、API連携の設定が済んでいないため**です。 会議データを扱う仕組みは、組織の管理権限に触れます。個人のアカウントでできることには限りがあり、管理者側の設定が前提になります。 **「作れば動く」ものと「許可がないと動かない」ものがあり、後者では権限の確保をスケジュールに含めておく必要があります。** ## 構成 ``` Google Meet（会議終了） ↓ Google Apps Script（議事録の生成） ↓ Discord へ通知 ``` Zoomで動かしている仕組みと同じ考え方です。会議プラットフォームが変わっても、**「終了をトリガーに、要約して、チャットへ流す」という構造は共通**で使えます。 ## Claude Codeでのベースコード実装 実装フェーズでは、**Claude Codeを使ってGASのベースコードを作成しました。**GASは書き慣れていないと調べる時間が発生しやすい領域ですが、ここは詰まらずに通っています。 この検証で明らかになったのは、**ボトルネックがコードを書く工程ではなくなっている**ということです。実装が速くなったぶん、権限や設定といった周辺の手続きが相対的に重く見えるようになりました。 ## 着手前に確認しておくべきこと 同じ構成を検討している場合、先に押さえておくとよい点です。 - **Google Workspace の管理権限があるか** — 誰が持っていて、いつ動かせるか - **必要なAPIの有効化を誰が行うか** — 管理者の作業が挟まる - **会議データの取り扱い方針** — 議事録を誰が見られる場所に流すか **コードが完成してから権限を取りにいくと、待ち時間がそのまま停滞になります。**並行して進めるほうが確実です。 ## よくある質問 ### なぜ動作確認まで進んでいないのですか？ **Google Workspace の管理権限とAPI連携設定が未完了のためです。**コード自体はClaude Codeで実装が完了しています。 ### Zoomでの仕組みと何が違いますか？ **構造は同じです。**会議終了をトリガーに要約してチャットへ通知する、という流れは共通で使えます。違いはプラットフォーム側の権限・API設定の手続きです。 ### GASでの実装は難しいですか？ 今回はClaude Codeを使ってベースコードを実装し、ここは詰まりませんでした。**実装よりも、権限や設定といった周辺の手続きのほうが時間を要しています。** ## まとめ - Google Meet の議事録自動作成・Discord通知について、**Claude CodeでGASのベースコードを実装完了** - ただし**Google Workspace の管理権限とAPI連携設定が未完了**のため動作確認に進めていない - 会議データを扱う仕組みは**組織の管理権限が前提**になる - 実装が速くなった今、**権限や設定の確保をスケジュールに含める**ことが重要になっている AI活用の停滞は、技術ではなく手続きで起きることがあります。着手前に「誰の許可が要るか」を洗い出しておくと、待ち時間を減らせます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務効率化とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Claude Code SDKでレビューを自動化する｜チャットではなく「プログラム的統合」が効く理由 - URL: https://ai-katsu.jp/articles/claude-code-sdk-workflow - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-06T00:00:00+00:00 - Models: Claude Code - Tasks: 業務自動化・ワークフロー, ツール検証 > Claude Code SDKでCI/CDパイプラインやPRレビューにAIを組み込む可能性を検証しました。チャット形式では人が起点になる回数しか動きませんが、SDK経由なら「PRが作られたら動く」形にできます。CLAUDE.mdによる指摘基準の固定が、自動レビューの信頼性を左右するという知見をまとめています。 Claude Codeはターミナルで使うツールですが、SDKを使えばPythonやTypeScriptのプログラムから呼び出せます。つまり**人が指示を出すのではなく、パイプラインの一部としてAIを組み込める**ということです。 CI/CDやPRレビューにAIを埋め込む可能性を検証しました。結論として、**開発プロセスのコアに組み込むなら、チャット形式よりSDK経由の統合が圧倒的に強力**という評価になりました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月（10/6〜10/7） | | 使用ツール | Claude Code SDK | | やりたかったこと | Claude Codeの機能をプログラムから呼び出し、CI/CDパイプラインやPRレビューにAIを組み込む | | 解決したい課題 | 定型的なコードレビュー、テストコード生成の完全自動化 | | 確認できたこと | **CLAUDE.mdを用いた一貫性のあるエージェント構築が可能** | | 判定 | 完了（検証継続） | > 本記事は自社での検証記録です。レビュー工数の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：チャットではなく「プログラム的統合」 この検証の核心はここです。 **開発プロセスのコアに組み込むなら、チャット形式よりもSDK経由の「プログラム的統合」が圧倒的に強力です。** チャットでAIを使う場合、実行するのは常に人間です。「レビューして」と依頼して、結果を読んで、直す。この形では**人が起点になる回数だけしか動きません。** SDKで組み込むと、起点がイベントに変わります。PRが作られたら動く、コミットが入ったら動く。**人が忘れても動く仕組みになる**ことが、定型作業の自動化では決定的な差になります。 ## CLAUDE.mdによる一貫性の担保 実装面で確認できたのが、**CLAUDE.mdを用いた一貫性のあるエージェント構築**です。 CLAUDE.mdはプロジェクトの文脈やルールを記述しておくファイルで、Claude Codeがこれを読んで振る舞いを合わせます。SDK経由で呼び出す場合も同様に効きます。 自動レビューで問題になりがちなのが、**指摘の基準がぶれること**です。同じような箇所で、あるときは指摘され、あるときは通る。これが起きると信用されなくなります。 **ルールをファイルとして固定できることが、自動化されたレビューを実用に耐えるものにします。** ## 向き不向き | | 評価 | | --- | --- | | CLIに馴染みのない層 | **不向き** | | 開発プロセスへの組み込み | **圧倒的に強力** | SDKを使う以上、コードを書く前提になります。**非エンジニアが触るものではありません。**逆に言えば、エンジニアリング組織が持つ定型作業を削るための道具として位置づけると噛み合います。 ## 想定している用途 - **定型的なコードレビュー** — 命名規則やパターンの逸脱など、基準が明文化できるもの - **テストコードの生成** — 実装に対する定型的なテストの雛形 - **CI/CDパイプラインへの組み込み** — 人の操作を待たずに走らせる ## よくある質問 ### チャットで使うのと何が違いますか？ **起点が人からイベントに変わります。**チャットは人が依頼したときだけ動きますが、SDK経由なら「PRが作られたら動く」といった形で自動的に走ります。定型作業の自動化ではこの差が大きくなります。 ### 非エンジニアでも使えますか？ **使えません。**SDKからプログラムで呼び出す前提のため、コードを書く必要があります。CLIに馴染みのない層には不向きという評価です。 ### レビューの基準はどう揃えますか？ **CLAUDE.mdにルールを記述することで、一貫性のあるエージェントを構築できます。**指摘基準がぶれると自動レビューは信用されなくなるため、ここを固定できる点は重要です。 ### どのくらい工数が減りますか？ **この検証では定量測定を行っていないため、数値はお答えできません。**SDK経由の統合が有効だという評価と、CLAUDE.mdによる一貫性の確認までの段階です。 ## まとめ - 開発プロセスのコアに組み込むなら、**チャット形式よりSDK経由の「プログラム的統合」が圧倒的に強力** - チャットは人が起点、SDKはイベントが起点。**人が忘れても動く仕組みになる** - **CLAUDE.mdで一貫性のあるエージェントを構築できる**。自動レビューでは基準の固定が信頼性を左右する - CLIに馴染みのない層には不向き。**エンジニアリング組織の定型作業を削る道具**として位置づける AIを業務に組み込むとき、「人がAIを使う」のか「仕組みの中でAIが動く」のかで、得られる効果はまったく違います。後者を狙うならSDKが選択肢に入ります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発内製化とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Figma→Webflowインポートで横並びが崩れる｜Auto LayoutとFlexboxの整合性という壁 - URL: https://ai-katsu.jp/articles/webflow-stitch-figma - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-10-02T00:00:00+00:00 - Tools: Figma, Webflow, Google Stitch - Tasks: 資料作成・デザイン, ツール検証 > Figmaで作成したデザインをWebflowへインポートし、コーディングなしでサイト公開するフローを検証しました。プラグイン利用時に横並び要素が縦並びに変換される不具合が発生。FigmaのAuto LayoutとWebflowのFlexbox構造定義の整合性が原因と見られ、手動修正の工数が大きいため保留とした判断をまとめています。 Figmaで作ったデザインをWebflowにインポートできれば、コーディングなしでサイトを公開できます。プラグインも用意されており、手順としては単純です。 実際に試したところ、**横並びに組んだ要素が縦並びに変換されるという不具合**が発生しました。修正の工数が大きいため、現時点では優先度を下げて保留としています。短い検証ですが、同じ構成を検討している方には判断材料になるはずです。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年10月2日 | | 使用ツール | Figma / Webflow / Stitch | | やりたかったこと | Figmaで作成したデザインをWebflowへインポートし、コーディングなしでサイトを公開する | | 発生した不具合 | **プラグインでのインポート時、横並び要素が縦並びに変換される** | | 原因の見立て | FigmaのAuto LayoutとWebflow側の構造定義（Flexbox等）の整合性 | | 判定 | 一部保留（手動修正の工数が大きいため優先度を下げた） | > 本記事は自社での検証記録です。検証が保留のため、成果や削減効果はありません。発生した不具合と判断の記録です。 ## 起きたこと：横並びが縦並びになる **プラグインを使ってFigmaからWebflowへインポートすると、横並びに配置した要素が縦並びに変換されました。** レイアウトの根幹に関わる部分なので、これが崩れると「インポートして微調整」では済みません。**実質的に組み直しに近い作業量になります。** ## 原因の見立て：Auto LayoutとFlexboxの解釈差 FigmaのAuto Layoutと、Webflow側のFlexboxによる構造定義。この2つの整合性が取れていないことが原因と見ています。 どちらも「要素を並べる」仕組みですが、内部の考え方は完全に一致しているわけではありません。**デザインツールとノーコードツールの間には、こうした構造の翻訳が挟まります。**ここでずれると、見た目が変わります。 ## 保留にした判断 対応するとすれば、**Webflow側の構造定義とFigmaのAuto Layoutの整合性を再調整する**ことになります。ただし現状は手動修正の工数が大きいため、優先度を下げて保留としました。 **「インポートしてから直す」が「最初から作る」より重くなるなら、自動化する意味がありません。**この損益分岐を越えていないと判断しました。 なお、別途検証したWebflow AIによるサイト生成では、ポン出しの品質は高いという評価が出ています。**Figmaからのインポートに固執せず、Webflow上で生成してしまうほうが早い場合があります。** ## よくある質問 ### Figma→Webflowのインポートは使えないということですか？ **今回の検証では、横並び要素が縦並びに変換される不具合が発生しました。**Auto Layoutの組み方によっては結果が変わる可能性はありますが、修正工数が大きいと判断して保留しています。 ### どう回避すればいいですか？ Webflow側の構造定義とFigmaのAuto Layoutの整合性を取ることが根本対応です。**ただし手動での再調整が必要になるため、Webflow上で直接生成する方法と比較してから選ぶことをおすすめします。** ## まとめ - Figma→Webflowのプラグインインポートで、**横並び要素が縦並びに変換される不具合**が発生 - 原因は**FigmaのAuto LayoutとWebflowのFlexbox構造定義の整合性**と見ている - 再調整は可能だが**手動修正の工数が大きく、優先度を下げて保留** - 「インポートして直す」が「最初から作る」より重いなら、自動化の意味がなくなる ツール間の連携は、手順が用意されていても構造の翻訳で崩れることがあります。導入判断では、変換後の修正工数まで含めて見積もる必要があります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の制作業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Indeed APIで応募者スクリーニングを自動化する｜着手前に判明した3つの前提条件 - URL: https://ai-katsu.jp/articles/indeed-api-candidate-judgment - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-27T00:00:00+00:00 - Tools: Indeed API, Google Apps Script - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: 採用・人事 > Indeedからの応募者情報を自動取得し、初期選考をAIでスコアリングする仕組みを検討しました。仕様調査の結果、APIだけでは完結せず自前のXMLフィード連携が必須であること、個人情報を扱うため実運用はGAS以外の環境が必要なこと、既存ATSとの競合という3点が判明。保留に至った判断過程をまとめています。 応募者への返信が遅れると、それだけで候補者を逃します。一方で書類選考は担当者ごとに基準がぶれやすい作業でもあります。この2つを同時に解決したくて、**Indeedからの応募者情報を自動取得し、初期選考をAIでスコアリングする仕組み**の検討を始めました。 結果は**保留**です。技術的に不可能だったわけではなく、既存システムとの整合と個人情報の取り扱いという、実装前に潰すべき論点が残ったためです。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月〜10月（9/27〜10/10） | | 使用ツール | Indeed Apply API / GAS | | やりたかったこと | 応募者対応のタイムラグ解消と、書類選考の判定基準の標準化 | | 技術要件として特定できたこと | **APIだけでは完結しない。自前でXMLフィードを作成し、Indeedがアクセスできる場所に配置する「フィード連携」との組み合わせが必須** | | 残った課題 | 既存の採用管理システム（ATS）との競合 | | 判定 | 保留 | > 本記事は自社での検証記録です。実装まで至っていないため、工数削減などの成果はありません。仕様調査と設計方針の整理までの記録です。 ## 結論：APIだけでは繋がらない 仕様調査で最も重要だった発見がこれです。 **Indeed Apply APIを使うには、自前でXMLフィードを作成し、Indeedがアクセス可能な場所に配置する「フィード連携」との組み合わせが必須でした。** 「APIキーを取得すれば繋がる」という想定で計画すると、ここで止まります。求人情報を渡す仕組み（フィード）と、応募者情報を受け取る仕組み（API）の両方を用意する必要があります。加えてパートナー申請の手続きも発生します。 **着手前にこの前提を把握できたこと自体が、この調査の成果でした。** ## 設計方針：個人情報を扱う以上、実行環境を分ける この検討で早い段階に決めた方針です。 **個人情報を取り扱うため、PoC（検証）はGASで行うが、実運用はVPSやMakeなどのよりセキュアな環境に切り替える**としました。 応募者の氏名・連絡先・職務経歴は、社内でも取り扱いに配慮が要る情報です。**検証段階で手軽に動かせることと、本番で預かってよいことは別の基準で判断すべき**という整理です。 「PoCで動いたからそのまま本番に」という流れは、個人情報を扱う仕組みでは避ける必要があります。 ## 保留の理由：既存ATSとの競合 技術面より先に解くべき問題として浮上したのがこれです。 **すでに利用している採用管理システム（ATS）との競合が発生します。**ATS側もIndeedとのエントリー連携に対応している場合、両方から取りに行くと処理が干渉する可能性があります。 対応として、**現在利用中のATSがIndeedエントリー連携に対応しているかを確認し、API干渉が起きない設計を検討中**という段階です。 応募者データが二重に流れたり、片方で既読になった応募がもう片方で未処理のまま残ったりすると、**効率化どころか対応漏れの原因になります。**ここを詰めずに実装するのは危険と判断しました。 ## この検証から言えること 採用まわりの自動化を検討する際に、先に確認しておくとよい点を整理します。 - **APIだけで完結するか** — フィード連携やパートナー申請など、周辺の要件を先に洗う - **既存のATSと役割が重ならないか** — 二重取得は対応漏れを生む - **個人情報の実行環境をどこにするか** — PoCと本番で基準を分ける ## よくある質問 ### Indeed Apply APIだけで応募者情報を取得できますか？ **できません。**自前でXMLフィードを作成し、Indeedがアクセス可能な場所に配置する「フィード連携」との組み合わせが必須です。加えてパートナー申請の手続きも必要になります。 ### なぜGASで本番運用しないのですか？ **個人情報を取り扱うためです。**検証段階の手軽さと、本番で個人情報を預かる際に求められる要件は別物です。実運用はVPSやMakeなど、よりセキュアな環境に切り替える方針としました。 ### なぜ保留になったのですか？ **既存の採用管理システム（ATS）との競合が解決していないためです。**ATS側もIndeed連携に対応している場合、応募データが二重に流れて対応漏れを招く恐れがあります。API干渉が起きない設計を先に固める必要があります。 ## まとめ - Indeed Apply APIは**単体では完結せず、自前のXMLフィード連携との組み合わせが必須** - 個人情報を扱うため、**PoCはGAS、実運用はVPS等のセキュアな環境**と方針を分けた - 保留の理由は**既存ATSとの競合**。二重取得による対応漏れのリスクを潰す必要がある - 採用の自動化では、技術要件より先に**既存システムとの役割分担**を確認したほうがよい 自動化の検討では「作れるか」より先に「既存の仕組みと衝突しないか」を確認したほうが、手戻りが減ります。特に人が絡む業務では、処理の重複がそのまま事故になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の採用業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 検索順位を自動で定点観測する｜Google Custom Search API×GASで競合をウォッチする - URL: https://ai-katsu.jp/articles/google-custom-search-competitor - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-27T00:00:00+00:00 - Tools: Google Custom Search API, Google Apps Script - Tasks: リサーチ・データ収集, 業務プロジェクト - Domain: マーケティング > 特定キーワードのオーガニック検索結果を自動収集し、競合の変動を定点観測する仕組みをGoogle Custom Search APIとGASで構築しました。APIで取ることでパーソナライズの影響を受けない生データが得られます。構成がシンプルで検索条件の追加をマニュアル化できる点と、次に計画しているLLMでの訴求変化レポート化をまとめています。 SEOの競合分析では、特定キーワードの検索結果を定点観測したい場面があります。しかし毎回手で検索して順位を控えるのは現実的ではありません。ブラウザで検索した結果は、パーソナライズの影響も受けます。 Google Custom Search APIとGASを組み合わせ、**キーワード別のランキングデータを自動取得してDiscordへ通知する仕組み**を構築しました。構成がシンプルなため、運用のマニュアル化まで見通せる形になっています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月27日 | | 使用ツール | Google Custom Search API / GAS / Discord | | やりたかったこと | 特定キーワードのオーガニック検索結果を自動収集し、競合の変動やトレンドを定点観測する | | できたこと | 検索エンジンIDとAPIキーによる**キーワード別ランキングデータの自動取得**とDiscord通知 | | 特徴 | 操作がシンプルなため、**検索条件の追加作業をマニュアル化できる**状態 | | 判定 | 完了（マニュアル化可能） | > 本記事は自社での検証記録です。工数削減の定量測定は行っていないため、数値は掲載していません。 ## 結論：シンプルだからこそ運用に乗る この検証の価値は、機能の派手さではなく**運用のしやすさ**にあります。 **操作がシンプルであるため、検索条件の追加作業を容易にマニュアル化できる状態になりました。**「このキーワードも追加で追いたい」という要望に、担当者が自分で対応できます。 自動化の仕組みは、作った人しか触れないと形骸化します。**手順書にできる程度の単純さを保つことは、それ自体が設計目標になり得ます。** ## 構成 ``` 1. Google Cloud Console で Custom Search API を有効化 2. 検索エンジンID と APIキー を取得 ↓ 3. GAS からキーワードを指定して検索結果を取得 ↓ 4. Discord へ通知 ``` 特別なサーバーは不要です。GASで動くため、実行環境の用意も要りません。 ## なぜAPIで取るのか ブラウザで手動検索した結果は、ログイン状態や検索履歴によるパーソナライズの影響を受けます。定点観測をしたい場合、これは邪魔になります。 **APIで取得すれば、条件を固定した生データが得られます。**戦略立案の素材としては、こちらのほうが扱いやすくなります。 ## 次の展開：LLMで「訴求の変化」をレポート化する 現時点では検索結果のデータを取得するところまでですが、次の一手を計画しています。 **取得したタイトル・スニペット情報をLLMに渡し、「競合の訴求ポイントの変化」を週次でレポート化する処理を追加する**というものです。 順位の上下だけを見ていても、なぜ動いたのかは分かりません。**タイトルやスニペットの文言がどう変わったかを追えば、競合が何を打ち出そうとしているかが見えます。**データを取るところまでは自動化できたので、次は解釈の部分をAIに任せる、という段階です。 ## よくある質問 ### 手動で検索するのと何が違いますか？ **パーソナライズの影響を受けない生データが取れます。**ブラウザでの検索結果はログイン状態や履歴に左右されるため、定点観測には向きません。 ### 非エンジニアでも運用できますか？ **構成がシンプルなため、検索条件の追加はマニュアル化できます。**初期構築（API有効化・キー取得）にはGoogle Cloud Consoleの操作が必要ですが、そこを越えれば運用は容易です。 ### 順位変動の理由まで分かりますか？ **現時点では取得までです。**今後、取得したタイトル・スニペットをLLMに渡し、競合の訴求ポイントの変化を週次レポート化する処理を追加する予定です。 ## まとめ - Google Custom Search API × GAS で、**キーワード別ランキングデータの自動取得**とDiscord通知を実現 - APIで取ることで、**パーソナライズの影響を受けない生データ**が得られる - 構成がシンプルなため、**検索条件の追加をマニュアル化できる**——運用に乗せやすい - 次は取得データをLLMに渡し、**競合の訴求ポイントの変化を週次レポート化**する計画 自動化では「高度な仕組みを作ること」より「担当者が自分で条件を足せること」のほうが、長く使われる条件になります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 商談記録とマーケ指標を統合する｜Zoom要約の自動転記とGoogle Ads本番昇格までの記録 - URL: https://ai-katsu.jp/articles/sales-marketing-auto-aggregation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-27T00:00:00+00:00 - Models: Gemini - Tools: Google Apps Script, Vercel, Zoom, Google Analytics 4 - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: 営業 > GA4・Google広告・Clarityのマーケ指標と、Zoomの商談結果を統合管理する基盤を構築しました。商談の文字起こし・要約のDiscord通知とスプレッドシート転記が安定稼働に入り、Google Ads開発者トークンの本番昇格も完了。認証の永続化が必要な処理をVercel Functionsに分けた設計判断をまとめています。 マーケティングの数字はGA4・Google広告・Clarityに散らばり、営業の記録はZoomの商談の中にあります。この2つを別々に見ている限り、「施策がどう成果に繋がったか」は繋がりません。 両方を統合して管理・分析し、**ネクストアクションの策定を高速化する基盤**を構築しています。商談の要約自動転記は安定稼働に入り、マーケ指標の自動通知も動き始めました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月〜10月（9/27〜10/10） | | 使用ツール | GAS / Vercel Functions / Zoom API / Gemini API / GA4・Clarity API | | やりたかったこと | マーケ指標と商談結果を統合管理し、ネクストアクション策定を高速化する | | 稼働したもの | 商談の要約・文字起こしのスプレッドシート自動転記とDiscord通知（**安定稼働**）／GA4・Clarityの自動通知 | | 前進した手続き | **Google Ads 開発者トークンの本番昇格** | | 状況 | 進行中（環境整備および一部実装完了） | > 本記事は自社での検証記録です。営業生産性の向上幅などの定量測定は行っていないため、数値は掲載していません。 ## 動き始めたもの ### 1\. 商談の文字起こし・要約の自動転記 **Zoom Webhookを起点に、商談の文字起こしと要約をDiscordへ通知し、スプレッドシートへ転記する仕組みが安定稼働に入りました。**現時点ではセールス1アカウントでの運用です。 商談が終わると、内容が自動でチームに共有され、記録として残る。この状態になると、**振り返りのために録画を開く必要がなくなります。** ### 2\. 担当者コメントの抽出 実装で細かく効いたのがこの部分です。**担当者コメントの抽出ロジック（ユーザー名のトリミング、文字数制限の考慮）を実装しました。** 文字起こしをそのまま流すと、発言者名の表記ゆれや長さで読みにくくなります。**通知として成立させるには、整形の細部を詰める必要があります。**ここは地味ですが、使われるかどうかを分ける部分です。 ### 3\. マーケ指標の自動通知 **GASによりGA4とClarityの自動通知環境を構築し、通知に成功しています。**これで数字の巡回作業が減ります。 ## Google広告：開発者トークンが本番昇格 手続き面での前進として、**Google Ads の開発者トークンが本番昇格しました。** Google Ads APIは、申請したトークンがテスト権限のままでは実データを扱えません。**本番昇格は、この仕組みを実運用に載せるための必須条件です。**あわせてOAuth認証のリフレッシュトークン処理も実装しています。 以前の検証でGoogle Ads APIの複雑さと認証の永続化が最大の障壁だと判明していたため、ここを越えられたのは大きな進展でした。 ## 構成 ``` Zoom（商談終了） ↓ Webhook GAS / Vercel Functions ↓ Gemini API で要約 Discord 通知 ＋ スプレッドシート転記 GA4 / Clarity / Google Ads API ↓ GAS Discord へ指標を自動通知 ``` GASとVercel Functionsを併用しているのは、**認証の永続化が必要な処理を、より安定した実行環境に置くため**です。すべてをGASに寄せず、役割で分けています。 ## よくある質問 ### 商談の要約はどこまで自動化されていますか？ **Zoom Webhookを起点に、文字起こしと要約のDiscord通知・スプレッドシート転記まで自動化され、安定稼働しています。**現時点ではセールス1アカウントでの運用です。 ### Google Ads APIは動いていますか？ **開発者トークンの本番昇格が完了し、OAuth認証のリフレッシュトークン処理も実装済みです。**Google Ads APIは申請区分によって実データを扱えないため、この昇格が実運用の前提になります。 ### なぜGASとVercel Functionsを併用しているのですか？ **認証の永続化が必要な処理を、より安定した環境で動かすためです。**すべてをGASに寄せると、トークンの更新まわりで不安定になる箇所が出ます。 ### どのくらい工数が減りましたか？ **この検証では定量測定を行っていないため、数値はお答えできません。**商談の振り返りで録画を開く必要がなくなった、という定性的な変化にとどまります。 ## まとめ - 商談の文字起こし・要約の**Discord通知とスプレッドシート転記が安定稼働**（セールス1アカウント） - **GA4・Clarityの自動通知に成功**し、数字の巡回作業を削減 - **Google Ads 開発者トークンの本番昇格**とリフレッシュトークン処理を実装。実運用の前提をクリア - 通知を「読まれるもの」にするには、**ユーザー名トリミングや文字数制限といった整形の細部**が効く - 認証の永続化が要る処理はGASに寄せず、**Vercel Functionsと役割分担**する 複数のデータソースを束ねる仕組みは、一気に完成させようとすると止まります。動いたところから順に運用へ載せていくほうが、結果的に早く価値が出ます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の営業・マーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## SNS予約投稿とインサイト収集をGASで自動化する｜Xは15分、Instagramは2時間 - URL: https://ai-katsu.jp/articles/sns-automation-x-instagram - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-23T00:00:00+00:00 - Tools: Google Apps Script, X（旧Twitter）, Instagram - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: マーケティング > 投稿漏れの防止とアナリティクス収集の自動化を目的に、GASでSNS運用基盤を構築しました。X API v2での予約投稿は約15分、Instagram Graph APIのインサイト取得まで含めて2時間で実装。Meta側の設定が煩雑という壁と、アクセストークンを2ヶ月ごとに交換すべき理由をまとめています。 SNS運用でいちばん失いやすいのは、投稿するタイミングそのものです。作ったのに出し忘れる、インサイトを見るのが後回しになる。この2つを潰すために、**GASを使ったSNS運用の自動化基盤**を構築しました。 Xの予約投稿は**15分程度**で構築でき、Instagramのインサイト取得まで含めて**2時間**で実装しています。Meta側の設定が煩雑という壁はありますが、一度越えれば扱いやすい構成でした。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月（9/23〜9/24） | | 使用ツール | GAS / X API v2 / Instagram Graph API / Facebook Developer Portal | | やりたかったこと | 投稿漏れの防止と、アナリティクス収集の自動化。戦略立案に集中できる環境をつくる | | 構築時間 | **Xの予約投稿環境：約15分／Instagramのインサイト取得まで：2時間** | | できたこと | スプレッドシート連動型の予約投稿、インサイトの自動取得、Discordへの自動通知 | | 状況 | X予約投稿は完了。基盤構築完了（進行中） | > 本記事は自社での検証記録です。運用工数の削減率などの測定は行っていないため、その数値は掲載していません。 ## 結論：Xは15分、Instagramは2時間 実装コストがはっきり分かれました。 **Xの予約投稿環境は、約15分の設定で構築できました。**GASとX API v2を組み合わせ、スプレッドシートに書いた内容が予定時刻に投稿される仕組みです。 一方、**Instagramのインサイト取得までを含めると2時間**かかっています。この差はほぼMeta側の設定手順に由来します。 ## 構成 ``` スプレッドシート（投稿内容・予定時刻を記入） ↓ GAS X API v2 → 予約投稿 Instagram Graph API → インサイト取得 ↓ GAS Discord へ自動通知 ``` **投稿内容をスプレッドシートに蓄積する構成にしたことが、副次的な効果を生みました。**過去の投稿がそのままデータベースになるため、バズった投稿との照らし合わせが容易になります。 予約投稿の仕組みを作ったつもりが、**投稿ログの蓄積装置にもなっていた**という形です。 ## つまずいたこと：Meta側の設定が煩雑 実装で最も時間を取られたのがここです。 **Instagram Graph API（Meta）は設定手順が非常に煩雑です。**Facebookページとの連携をはじめ、通らなければならない手順が多くあります。Xと比べて構築時間に大きな差が出たのは、ほぼこの部分です。 ただし**一度繋がってしまえば、curlやGASから容易に操作できます。**難所は入口に集中しており、運用フェーズは扱いやすい構成です。 ## セキュリティ：アクセストークンの管理 運用にあたって重要な注意点です。 **アクセストークンの漏洩リスクを考慮し、2ヶ月ごとの交換（または管理の厳格化）が必須**と整理しました。 SNSアカウントのトークンが漏れると、投稿を乗っ取られる可能性があります。**自動化の仕組みを作るときは、動かすことと同じくらい、鍵をどう扱うかを決めておく必要があります。**定期交換をルールとして先に決めておくのが確実です。 ## よくある質問 ### Xの予約投稿は本当に15分で作れますか？ **約15分程度の設定で構築できました。**GASとX API v2を使い、スプレッドシートと連動させる構成です。Instagram側と比べると、必要な手順が大幅に少なくて済みます。 ### Instagramの設定が難しいと聞きますが **そのとおりです。**Instagram Graph APIはFacebookページ連携などの手順が煩雑で、ここに時間を取られます。ただし一度繋がればcurlやGASから容易に操作できるため、難所は初回のみです。 ### アクセストークンはどう管理すべきですか？ **2ヶ月ごとの交換、または管理の厳格化を推奨します。**漏洩するとアカウントを操作されるリスクがあるため、運用ルールとして先に決めておくべき項目です。 ### 投稿の分析もできますか？ Instagramのインサイトを自動取得し、Discordへ通知する仕組みまで実装しています。加えて**投稿内容をスプレッドシートに蓄積しているため、過去のバズ傾向との照らし合わせが容易になりました。** ## まとめ - **Xの予約投稿環境は約15分**、**Instagramのインサイト取得まで含めて2時間**で実装 - 時間差の主因は**Meta側の設定手順の煩雑さ**。ただし一度繋がれば扱いやすい - 投稿内容をスプレッドシートに蓄積したことで、**過去のバズ傾向との照合が容易に** - **アクセストークンは2ヶ月ごとの交換が必須**。自動化と同時に鍵の運用ルールを決める SNS運用の自動化は、投稿を自動化するだけでなく「投稿のログが自然に貯まる」構造にすると価値が伸びます。あとから振り返れる状態を作っておくことが効いてきます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のマーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Webflow AIでサイトを生成する｜インタラクション実装の強みと、修正が煩雑という弱点 - URL: https://ai-katsu.jp/articles/webflow-ai-site - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-22T00:00:00+00:00 - Models: Gemini - Tools: Webflow, Google Stitch - Tasks: 資料作成・デザイン, ツール検証 > Webflow AIのSite Builderが既存の制作ワークフローを代替できるかを検証しました。ポン出しの品質は高くGSAP連携やコードエクスポートにも対応、特にインタラクションをノーコードで組める点はエンジニアにも効果大。一方で修正にはWebflow固有の知識が必須なため、修正回数自体を減らす「多段階指示法」に至った経緯をまとめています。 Webflow AIの「Site Builder」は、指示からサイトを丸ごと生成します。既存の制作ワークフロー（Figma → STUDIO / WordPress）を代替できるのか、実際に触って確認しました。 結果として、**ポン出しのクオリティは高く、特にインタラクションの実装で工数削減の効果が大きい**と評価しました。一方で、修正の段階に固有のハードルがあります。それを回避するための「多段階指示法」まで含めて共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月（9/22〜9/23） | | 使用ツール | Webflow AI（Site Builder） | | やりたかったこと | 既存の制作ワークフロー（Figma → STUDIO / WordPress）を代替できるか検証する | | 良かった点 | ポン出しのクオリティが高い。**GSAP連携・コードエクスポートに対応** | | ハードル | インターフェースが英語のみ。ネストが深く編集が煩雑。修正にWebflow固有の知識が必須 | | 判定 | 完了（運用フローの定義） | > 本記事は自社での検証記録です。制作時間の短縮率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：インタラクションをノーコードで組めるのが大きい この検証で最も評価が高かったのがここです。 **スクロールアニメーションなどのインタラクションを、ノーコードで設定できます。これはエンジニアにとっても工数削減のメリットが大きい**という評価になりました。 動きの実装は、コードで書くと調整の往復が発生しがちな領域です。「もう少しゆっくり」「もう少し遅らせて」という微調整を、コードとブラウザを行き来しながら詰めていく作業になります。ここが画面上で完結するのは、非エンジニアだけでなく実装者にとっても効きます。 GSAP（アニメーションライブラリ）との連携にも対応しており、**コードエクスポートもできる**ため、Webflowの中に閉じ込められる心配も少なくなっています。 ## つまずいたこと：修正段階のハードル 生成そのものより、そのあとが問題でした。 **ポン出し後の修正には、Webflow固有の知識が必須です。**パディング、マージン、ネスト構造といった、Webflowの構造理解が前提になります。 加えて次の2点が重なります。 - **インターフェースが英語のみ** - **ネストが深く、編集が煩雑** 「AIが作ってくれるから誰でも使える」とはなりません。**生成は簡単でも、直すには習熟が要る**という構造です。 ## 対策：多段階指示法 この「修正が煩雑」という問題への対応として、**そもそも修正を減らす**アプローチを採りました。 ``` 1. Stitch 等で「理想の構成」を作る ↓ 2. Gemini 等でその構成を構造化する ↓ 3. 構造化した指示を Webflow AI にプロンプトとして与える ``` **いきなりWebflow AIに投げるのではなく、前段で構成を固めてから渡す**という進め方です。指示が具体的なほど生成物が意図に近づき、後工程の修正が減ります。 Webflow上での編集が煩雑である以上、**編集回数そのものを減らす方向に投資するほうが合理的**という判断です。 ## 既存ワークフローを代替できるか 当初の問いに対する答えは、**「用途による」**というものでした。 | 観点 | 評価 | | --- | --- | | デザイン素案の生成 | ポン出しの品質が高く、実用的 | | インタラクション実装 | ノーコードで組める。**最も価値が出る領域** | | 細かい修正作業 | Webflow固有の知識が必要。習熟コストあり | | チームでの運用 | 英語UIとネストの深さがハードルになる | ## よくある質問 ### 非エンジニアでも使えますか？ **生成はできますが、修正には習熟が必要です。**パディング・マージン・ネスト構造といったWebflow固有の知識が前提になります。インターフェースも英語のみです。 ### 作ったサイトはWebflowから出せますか？ **コードエクスポートに対応しています。**プラットフォームに閉じ込められる心配は比較的少ない構成です。 ### 修正が煩雑なのはどう解決しましたか？ **修正回数そのものを減らす方向で対応しました。**Stitch等で理想の構成を作り、Geminiで構造化し、その指示をWebflow AIに渡す「多段階指示法」です。前段で具体化するほど、後工程の修正が減ります。 ## まとめ - Webflow AIは**ポン出しのクオリティが高く、GSAP連携・コードエクスポートにも対応** - 最大の価値は**インタラクションをノーコードで設定できる点**。エンジニアにも工数削減効果が大きい - 一方、**修正にはWebflow固有の知識が必須**。英語UIとネストの深さもハードル - 対策は**「多段階指示法」**——Stitchで構成 → Geminiで構造化 → Webflow AIへ投入 - 編集が煩雑な以上、**編集回数を減らす方向に投資する**のが合理的 生成AIツールの評価では、生成の質だけでなく「直しやすさ」を見る必要があります。直しにくいツールほど、最初の指示に投資する価値が高くなります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の制作業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## まじん式プロンプトでスライドを自動生成する｜無料で作れる範囲と、向かない資料 - URL: https://ai-katsu.jp/articles/majin-prompt-presentation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-19T00:00:00+00:00 - Models: Gemini - Tools: Google Apps Script, Google Workspace - Tasks: 資料作成・デザイン, ツール検証 > GASとGeminiでGoogleスライドを自動生成する「まじん式プロンプト」の実用性を検証しました。DeepResearchで構造化した情報をソースにすれば、有料ツールなしで高品質な構成のスライドが作成可能。一方でデザインは白背景にテキストのみに限定されるため、「構成案の視覚化」と位置づけるハイブリッド運用に至った経緯をまとめています。 Googleスライドの作成は、構成を考えるところからレイアウトを整えるところまで、工数がかかります。特に「話す内容は頭にあるが、スライドの形にする作業が面倒」という状態は、多くの人が経験するところです。 SNSやコミュニティで話題になった**「まじん式プロンプト」——GASを使ってGoogleスライドを自動生成する手法**の実用性を検証しました。結論として、**シンプルなテキスト主体の資料なら、ほぼ修正不要なレベルに到達します。**ただし向き不向きがはっきりしています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月19日 | | 使用ツール | Googleスライド / Google Apps Script（GAS）/ Gemini 2.0 Flash・Pro | | やりたかったこと | 構成案の言語化からスライド化までの断絶をなくし、デザイン知識がなくても短時間で「伝わるスライド」の骨組みを作る | | 結論 | **シンプルなテキスト主体の資料なら、ポン出しでほぼ修正不要** | | 不向きな用途 | 企業向けの込み入ったデザイン、カラフルな装飾、複雑な図解を含むスライド | | 運用方針 | 「完成品の出力」ではなく**「構成案の迅速な視覚化」**と位置づけ、仕上げは手動で行うハイブリッド運用 | > 本記事は自社での検証記録です。作成時間の短縮率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：無料で高品質な構成のスライドが作れる この検証で最も価値のあった発見がこれです。 **DeepResearchで深掘りした質の高い情報をソースにすれば、GensparkやManusといった有料の外部ツールに頼らなくても、高品質な構成のスライドが無料で作成できます。** スライド生成ツールは有料のものが増えていますが、**この手法はGoogleスライドとGAS、そしてGeminiという既存の環境だけで完結します。**追加のサブスクリプションが不要という点は、社内展開を考えるうえで小さくない差になります。 ## 処理の流れ ``` 1. DeepResearch でスピーチ原稿や構造化された情報を生成 ↓ 2. 「まじん式プロンプト」に流し込む ↓ 3. GAS を介して Google スライドへ出力 ↓ 4. 必要に応じて手動で微調整 ``` ポイントは**1番目の工程**です。いきなりスライドを作らせるのではなく、先に情報を構造化してからプロンプトに渡します。**ソースの質がそのまま出力の質になります。** ## できること：テキスト主体なら修正不要のレベル **シンプルなテキスト主体のプレゼン資料であれば、ポン出しの段階でほぼ修正不要なレベルまで到達します。** 構成の言語化からスライド化までの「断絶」がなくなることが、実務での意味です。頭の中にある話の流れを、そのままスライドの形で確認できます。 ## できないこと：デザインは白背景にテキストのみ 一方で、制約ははっきりしています。 **デザインが極めてシンプル（白背景にテキスト）に限定されます。**そのため次のような用途には向きません。 - 企業向けの込み入ったデザインが求められる資料 - カラフルな装飾を使いたい資料 - 複雑な図解を含む資料 ブランドガイドラインに沿った体裁が必要な提案資料などは、この手法だけでは完結しません。 ## 運用方針：完成品ではなくプロトタイプとして使う 制約を踏まえた結論がこれです。 **本手法を「完成品の出力」ではなく、あくまで「構成案の迅速な視覚化（プロトタイピング）」と位置づけ、仕上げの微調整は手動で行うハイブリッド運用を標準としました。** 構成を固めるまでをAIに任せ、見た目を整える工程は人が引き取る。**資料作成で時間を食うのは実は構成の検討なので、そこが速くなるだけでも効果は十分あります。** ## よくある質問 ### 有料のスライド生成ツールは不要になりますか？ 用途によります。**テキスト主体のシンプルな資料であれば、この手法で無料で作れます。**ただしデザイン性が求められる資料には向かないため、そちらは別の手段が必要です。 ### デザインは調整できますか？ **白背景にテキストという極めてシンプルな形に限定されます。**装飾や複雑な図解は含められません。仕上げは手動で調整する前提で使ってください。 ### プロンプトに渡す情報はどう用意しますか？ **DeepResearch機能で事前に深掘りし、構造化された情報を用意することを推奨します。**ソースの質が出力の質に直結するため、ここを省略すると結果が落ちます。 ### どのくらい時間が短縮できますか？ **この検証では定量測定を行っていないため、数値はお答えできません。**「テキスト主体ならポン出しでほぼ修正不要」という定性的な評価にとどまります。 ## まとめ - Googleスライド × GAS × Gemini で、**構成案からスライドへの自動変換プロセスを確立** - **シンプルなテキスト主体の資料なら、ポン出しでほぼ修正不要** - DeepResearchで質の高い情報をソースにすれば、**有料ツールなしで高品質な構成が作れる** - ただし**デザインは白背景にテキストのみ**。企業向けの装飾や複雑な図解には不向き - 運用方針は**「完成品」ではなく「構成案の迅速な視覚化」**。仕上げは手動のハイブリッド 資料作成で本当に時間を食うのは、見た目より構成の検討です。そこだけを切り出して速くする、という割り切りが実務では効きます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の資料作成業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Gemini CanvasとStitchでUIを作る｜デザインと実装のギャップを埋めるのはどちらか - URL: https://ai-katsu.jp/articles/ai-design-gemini-canvas-stitch - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-18T00:00:00+00:00 - Models: Gemini - Tools: Google Stitch - Tasks: 資料作成・デザイン, ツール検証 > GeminiのCanvas機能とGoogleの実験的ツールStitchを、ラピッドプロトタイピング用途で検証しました。StitchはHTML/Tailwind CSS/JSXを即時エクスポートでき実装への橋渡しに強い一方、Canvasはコピペを省くエディタとして優秀。プレビューの制約と、実装環境へ引き継ぐフローの標準化をまとめています。 Figmaを開く前の段階——「とりあえず形にして議論したい」というラピッドプロトタイピングの局面で、非デザイナーでも高品質なUIが作れるのか。GeminiのCanvas機能と、Googleの実験的ツールStitchを検証しました。 結論として、**この2つは役割が異なり、組み合わせるものだと分かりました。**そして両方とも「デザイン検証用」と割り切ることで実用的になります。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月18日 | | 使用ツール | Gemini Canvas / Stitch（いずれもGoogle） | | やりたかったこと | Figma等を使う前段階のラピッドプロトタイピングで、非デザイナーでも高品質なUI/UXを構築できるか | | Gemini Canvas | モックアップの即時生成。**コピペの手間を省くエディタとして優秀** | | Stitch | PC/スマホ両対応のレスポンシブUI自動生成。**HTML/Tailwind CSS/JSXを即時エクスポート** | | 判定 | 完了（適応領域の特定） | > 本記事は自社での検証記録です。制作時間の短縮率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：Stitchはデザインと実装のギャップを埋める この検証で最も価値の大きかった発見がこれです。 **StitchはHTML / Tailwind CSS / JSXを即時エクスポートできるため、デザインからフロントエンド実装へのギャップを埋めるのに極めて強力です。** デザインツールの多くは「見た目」を出力します。そこから実装に移すには、人が改めてコードを書く工程が必要でした。Stitchはその段差を飛ばします。しかもPC・スマホ両対応のレスポンシブUIを自動で生成します。 「デザインを作る」と「実装に渡す」の間にある手間が消える、というのが実務での意味です。 ## Gemini Canvasの位置づけ：エディタとして優秀 Gemini Canvasについては、モックアップの即時生成が可能でした。特に**コピペの手間を省くエディタとして優秀**という評価です。 チャットで生成されたコードを別のエディタに貼り付けて確認する、という往復がなくなります。生成と確認が同じ場所で完結するぶん、試行のサイクルが速くなります。 ## 制約：Canvas内のプレビューには限界がある 一方で、Canvas内のプレビュー機能には無視できない制約がありました。 - **チャートが表示されない** - **レスポンシブの詳細確認ができない** データ可視化を含む画面や、画面幅ごとの挙動を詰めたい場面では、Canvas内だけで判断しきれません。 ### 対応：デザイン検証用と割り切って引き継ぐ この制約を踏まえて、次のフローを標準としました。 ``` Gemini Canvas / Stitch → デザイン検証・方向性の合意 ↓ 引き継ぐ Cursor / Vercel など → 詳細な実装 ``` **「ここで完成させよう」とせず、検証が終わったら実装環境へ渡す。**この割り切りが、制約を問題にしないための鍵でした。 ## Canvasで複雑なアプリを作るときのコツ 検証の中で得られた実務的なTipsです。 **Gemini Canvasで複雑なアプリを作る場合は、ライブラリ依存を避け、プレーンなReact等でバイブコーディング（対話型実装）を行うのが現実的です。** 外部ライブラリに依存した構成は、Canvas上のプレビューで期待どおりに動かないことがあります。**環境に持ち込むものを減らすほど、生成と確認のサイクルが安定します。** ## 試したこと 検証では次の3つのシナリオを実施しました。 1. Gemini Canvasでのアプリクローン作成 2. Stitchによるレスポンシブデザイン生成 3. 幅優先探索アルゴリズムのアニメーション視覚化 3つ目のアルゴリズム可視化まで扱えた点は、Canvasの応用範囲の広さを示しています。 ## よくある質問 ### Gemini CanvasとStitch、どちらを使えばいいですか？ **役割が違うため、目的で選んでください。**手早くモックアップを作って試行を回したいならGemini Canvas、レスポンシブUIを生成して実装に繋げたいならStitchです。Stitchはコードのエクスポートまで対応しています。 ### 非デザイナーでも使えますか？ ラピッドプロトタイピングの範囲であれば使えます。**ただし「完成品を作る」用途には向きません。**デザイン検証用と割り切り、詳細な実装は別環境に引き継ぐフローを推奨します。 ### Canvasでチャートが表示されないのですが **これはCanvas内プレビューの制約です。**レスポンシブの詳細確認も同様にできません。チャートを含む画面の確認は、CursorやVercelなど実装環境に引き継いでから行ってください。 ## まとめ - **StitchはHTML/Tailwind CSS/JSXを即時エクスポート**でき、デザインと実装のギャップを埋める - **Gemini Canvasはコピペの手間を省くエディタとして優秀**。モックアップの即時生成に向く - Canvas内プレビューには**チャート非表示・レスポンシブ詳細確認不可**という制約がある - 対応は**「デザイン検証用」と割り切り、詳細実装はCursor/Vercel等へ引き継ぐ**フローの標準化 - Canvasで複雑なアプリを作る際は、**ライブラリ依存を避けプレーンなReact等で組む**のが現実的 プロトタイピングツールは「どこまで作るか」を決めておかないと、途中で行き詰まります。引き継ぎ先を先に決めておくほうが、結果的に速く進みます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の制作業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## YouTubeのバズ動画リサーチを自動化する｜Makeの標準モジュールを捨ててAPIを直接叩いた理由 - URL: https://ai-katsu.jp/articles/youtube-api-make-research - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-16T00:00:00+00:00 - Tools: YouTube Data API, Make - Tasks: リサーチ・データ収集, 業務プロジェクト - Domain: マーケティング > YouTube上の動画リサーチと競合分析を自動化し、収集作業をほぼゼロに短縮しました。Makeの標準モジュールでは詳細検索に限界があったため、YouTube Data API v3を直接叩くカスタムロジックへ切り替え。高度なフィルタリングとクォータ節約を両立させた設計と、非エンジニアへ展開するためのテンプレート化をまとめています。 YouTubeのバズ動画リサーチや競合分析は、やること自体は単純です。条件に合う動画を探して、再生数と投稿日を控えて、リストにする。単純だからこそ、手作業でやると膨大な時間を吸われます。 MakeとYouTube Data APIを組み合わせ、**この動画収集作業をほぼゼロにしました。**Makeの標準モジュールでは足りず、APIを直接叩く構成に切り替えたことが鍵でした。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月（9/16〜9/17） | | 使用ツール | Make / YouTube Data API v3 | | やりたかったこと | 手動での動画収集・数値チェック（再生数・投稿日等）の工数を削減する | | 成果 | **動画収集にかかる作業時間をほぼゼロに短縮。**条件に合致する動画リストをスプレッドシート等へ即座に蓄積 | | 設計判断 | Makeの標準モジュールでは詳細検索に限界があったため、**「API Call」で直接叩くカスタムロジック**を構築 | | 判定 | 完了（汎用ロジック確立） | > 本記事は自社での検証記録です。削減時間の実測は行っていないため、「ほぼゼロ」という定性的な表現にとどめています。 ## 結論：標準モジュールを捨ててAPIを直接叩く この検証で最も重要な判断がこれです。 **Makeの標準モジュールでは、詳細な検索条件を指定するのに限界がありました。**そこで標準機能に頼らず、YouTube Data APIを直接叩く「API Call」モジュールでカスタムロジックを組みました。 この切り替えには2つの効果がありました。 - **高度なフィルタリングが可能になる** — 投稿期間、言語、並び順などを細かく指定できる - **クォータ（API利用制限）を節約できる** — 必要なデータだけを取りに行けるため無駄が減る ノーコードツールは標準モジュールで組むのが本来の使い方ですが、**「痒いところに手が届かない」と感じたらAPIを直接叩く選択肢を持っておくと、できることの幅が変わります。** ## 精度の高いリサーチ環境をどう作るか 検索パラメータを調整できるようになったことで、リサーチの質そのものが変わりました。 | 調整項目 | 効果 | | --- | --- | | 投稿期間 | 直近のトレンドだけに絞れる | | 言語 | 対象とする地域の動画だけを拾える | | 並び順 | 再生数順・新着順などリサーチ目的に合わせられる | 条件に合致した動画は、**スプレッドシート等へ即座に蓄積されます。**あとは溜まったリストを見て判断するだけ、という状態になりました。 ## つまずいたこと：非エンジニアへの展開 実用面での課題がこれです。**APIの仕様理解が必要になるため、非エンジニアにそのまま渡すことができません。** API Callを使う構成は柔軟な反面、パラメータの意味が分からないと触れません。「キーワードを変えたい」というだけの用事でも、エンジニアに依頼することになってしまいます。 ### 対応：パラメータ化してテンプレート化する 解決策として、**設定値をパラメータ化し、ユーザーがキーワードや期間を書き換えるだけで済むテンプレート**を作成しました。 APIの複雑さはテンプレートの中に隠し、**触る場所を「キーワード」「期間」だけに絞る**という設計です。これで非エンジニアにも展開できる形になりました。 > 自動化を組織で使うときは、作った本人以外が触れるかどうかで定着が決まります。**「どこを触ってよいか」を絞ることが、そのままマニュアルの代わりになります。** ## 次の展開：GASへの移植 今後の方針として、**同様のロジックをGAS（Google Apps Script）へ移植する**ことを検討しています。狙いは実行コストの完全無料化と、さらなる柔軟性です。 Makeは組み立てが速い一方、実行回数に応じたコストが発生します。ロジックが固まった後は、GASに移すほうが安く運用できます。 ## よくある質問 ### Makeの標準モジュールでは何が足りないのですか？ **詳細な検索条件の指定に限界があります。**投稿期間や言語、並び順といったパラメータを細かく制御したい場合は、API Callで直接叩く必要がありました。 ### APIのクォータは大丈夫ですか？ **むしろAPI Callのほうが節約できます。**標準モジュールは余分なリクエストが発生しがちですが、直接叩けば必要なデータだけを取りに行けます。 ### 非エンジニアでも使えますか？ そのままでは難しいため、**設定値をパラメータ化したテンプレートを作成しました。**ユーザーはキーワードと期間を書き換えるだけで使えます。API仕様の理解は不要です。 ### どのくらい時間が短縮できましたか？ **動画収集の作業時間はほぼゼロになりました。**ただし実測は行っていないため、具体的な削減時間はお答えできません。 ## まとめ - Make × YouTube Data API v3 で、**動画収集の作業時間をほぼゼロに短縮** - 標準モジュールでは詳細検索に限界。**API Callで直接叩くカスタムロジック**に切り替えた - この切り替えで**高度なフィルタリングとクォータ節約を同時に実現** - 非エンジニアへの展開には、**設定値をパラメータ化したテンプレート化が必須** - 次はGASへ移植し、実行コストの無料化を目指す ノーコードツールは「標準機能で組む」のが基本ですが、限界を感じたときにAPIへ降りられるかどうかで、実現できる範囲が大きく変わります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 商談録画をAIで解析する｜ネクストアクション抽出は形になり、感情分析は精度が課題 - URL: https://ai-katsu.jp/articles/sales-dx-emotion-analysis - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-08T00:00:00+00:00 - Models: Gemini - Tools: Zoom, Make, Google Apps Script - Tasks: 音声・翻訳・文字起こし, 業務プロジェクト - Domain: 営業 > Zoom商談の録画と文字起こしをAIで自動解析し、振り返り時間の削減と「刺さり具合」の定量評価を試みました。Zoom AIコンパニオンの出力を加工してネクストアクションを抽出する手法は確立できた一方、感情変化のサマライズは精度にばらつき。長時間動画のAPI制限への対処法とあわせてまとめています。 商談の振り返りは重要ですが、録画を見返す時間はなかなか取れません。そして「刺さっていたかどうか」の判断は、どうしても担当者の主観に寄ります。 Zoom商談の録画と文字起こしをAIで自動解析し、**ネクストアクションの抽出と、相手の反応の可視化**を試みました。文字起こしの活用は形になった一方、感情解析には精度のばらつきという課題が残っています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月（9/8〜9/12） | | 使用ツール | Zoom AI Companion / Make / Gemini API / GAS | | やりたかったこと | 録画を見返す時間の削減と、主観に頼らない「刺さり具合」の定量評価 | | できたこと | 商談後の文字起こしをDiscordへ自動通知し、スプレッドシートに記述する基本フローの設計 | | 確立した手法 | Zoom AIコンパニオンの出力をプロンプトで加工し、**営業が即座に動けるネクストアクションとして抽出** | | 課題 | 感情変化のサマライズに精度のばらつき。長時間動画はAPI制限で丸ごと解析できない | > 本記事は自社での検証記録です。工数削減や精度の定量測定は行っていないため、数値は掲載していません。 ## 結論：文字起こしの活用は形になった この検証で最も実用に近づいたのがこれです。 **Zoom AIコンパニオンの出力をプロンプトで加工し、「営業メンバーが即座に動けるネクストアクション」として抽出する手法を確立しました。** 商談の文字起こしはそのままだと長すぎて読まれません。要約しても「こういう話をしました」で終わってしまい、次の行動に繋がらないことがあります。**出力の形を「次に何をするか」に固定することで、読まれる情報に変わりました。** あわせて、商談終了後の文字起こしデータをDiscordへ自動通知し、スプレッドシートに記録する基本フローも設計しています。 ## 構成 ``` Zoom（商談終了・録画完了） ↓ Webhook Make（データ取得） ↓ 文字起こしをプロンプトで加工 ↓ Discord へ通知 ＋ スプレッドシートへ記録 ``` ## つまずいたこと1：長時間動画は丸ごと解析できない Gemini APIで動画解析（感情推定、声のトーン分析）を試みた際の技術的な発見です。 **長時間動画をそのまま解析しようとすると、API制限に引っかかります。**商談は30分〜1時間が普通なので、この制約は避けて通れません。 現実的な解として特定できたのは次の2つです。 - **5分単位で分割して処理する**（ffmpeg等を使う） - **Geminiアプリへ手動でアップロードする** 全自動にこだわると詰まりますが、**分割するか手動を挟むかを許容すれば動きます。** ## つまずいたこと2：感情解析の精度にばらつき 今回の主要な課題がこれです。**動画解析における「感情変化のサマライズ」の精度にばらつきが出ました。** 「刺さり具合を定量化する」という当初の目的に対して、現時点の出力は判断材料として信頼しきれません。日によって、あるいは商談によって、結果の質が揺れます。 ### 検討している対策：ハイブリッド解析 対応として検討しているのが、**解析をAIに丸投げせず、2つを組み合わせる方式**です。 | 担当 | 役割 | | --- | --- | | MediaPipe等 | 表情スコアの**数値化** | | Gemini | 数値を踏まえた**文脈の解釈** | **数値化できる部分は専用のツールに任せ、AIには解釈だけをさせる**という切り分けです。感情のような曖昧な対象ほど、全部をAIに投げると再現性が落ちます。 ## コスト面の課題：MakeからGASへ 実行基盤についても見直しの必要が出ました。 **MakeやZapierは実行コストが高いため、今後はGAS（Google Apps Script）による自前実装へシフトする方針です。**ただしその場合、OAuth認証の壁を突破する必要があります。 ノーコードツールは立ち上がりが速い反面、**実行回数が増えるほどコストが効いてきます。**検証段階はMake、運用段階はGAS、という切り替えは現実的な選択です。 ## よくある質問 ### 商談の感情分析は実用レベルですか？ **現時点では精度にばらつきがあり、判断材料としては不十分です。**表情スコアの数値化とAIによる文脈解釈を組み合わせるハイブリッド方式を検討中です。 ### 長い商談動画はどう扱えばいいですか？ **5分単位での分割（ffmpeg等）か、Geminiアプリへの手動アップロードが現実的です。**長時間動画を丸ごとAPIに投げるとAPI制限に引っかかります。 ### MakeとGAS、どちらを使うべきですか？ 用途によります。**Makeは立ち上がりが速い一方、実行コストが高くなります。**運用に乗せるならGASによる自前実装のほうが安く済みますが、OAuth認証の実装が必要です。検証はMake、運用はGASという使い分けが現実的です。 ### どのくらい振り返りの時間が減りましたか？ **この検証では定量測定を行っていないため、数値はお答えできません。**ネクストアクション抽出の手法を確立した段階です。 ## まとめ - Zoom AIコンパニオンの出力を加工し、**営業が即座に動けるネクストアクションとして抽出する手法を確立** - 文字起こしをDiscordへ通知しスプレッドシートに記録する基本フローを設計 - **長時間動画は丸ごと解析できない。**5分単位の分割か手動アップロードが現実解 - **感情変化のサマライズは精度にばらつき。**表情スコアの数値化＋AIの文脈解釈というハイブリッドを検討中 - Make/Zapierは実行コストが高いため、運用段階はGASへのシフトを想定 曖昧な対象をAIに評価させるときは、丸投げせず「数値化できる部分」と「解釈する部分」を分けたほうが安定します。今回はその設計に至った検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の営業DXとAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## GA4・Google広告・Clarityの指標を自動通知する｜API制限と認証の壁で方針転換した記録 - URL: https://ai-katsu.jp/articles/ga4-gads-clarity-report - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-09-01T00:00:00+00:00 - Tools: Google Analytics 4, Google Ads, Microsoft Clarity, Make - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: マーケティング > マーケティング指標をDiscordへ定期自動通知する仕組みを検証しました。Clarityは1日10回というAPI制限があり設計を左右する一方、最大の障壁はGoogle Ads APIの複雑さとOAuth認証の永続化。Makeでの認証維持を諦め、認証基盤の自前構築へ舵を切った判断と、全自動を急がない段階的アプローチをまとめています。 GA4、Google広告、Microsoft Clarity。マーケティングの数字は複数のダッシュボードに散らばっていて、確認するだけで毎日それなりの時間を使います。「重要指標だけDiscordに毎日流してほしい」——営業サイドからのこの要望が出発点でした。 結果として、**全自動化は一旦保留し、認証基盤の構築に舵を切りました。**技術的に何が壁になったのか、そしてどこから段階的に進めることにしたのかを共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年9月（9/1〜9/12） | | 対象API | Google Analytics API / Google Ads API / Clarity Data Export API | | やりたかったこと | GA4・Google広告・Clarityの重要指標を、Discordへ日次／週次／月次で自動通知する | | 最大の障壁 | **Google Ads APIの複雑さ。OAuth認証の永続化（リフレッシュトークン管理）** | | 重要な制限 | **Clarityは1日10回というAPI制限**があり、取得タイミングの最適化が必須 | | 判定 | 一部保留（認証基盤の構築へシフト） | > 本記事は自社での検証記録です。工数削減の定量測定は行っていないため、数値は掲載していません。 ## 調査結果：APIの利用制限に大きな差がある まず着手したのが、各ツールのAPI利用制限（Quotas）の調査です。ここで重要な差が見つかりました。 | API | 利用制限 | 評価 | | --- | --- | --- | | GA4 | 制限に余裕がある | 頻繁な取得も可能 | | **Clarity Data Export** | **1日10回** | 取得タイミングの最適化が必須 | **Clarityの1日10回という制限は、設計に直接影響します。**「必要なときに叩けばいい」という前提が成り立たないため、いつ取得して、どこにキャッシュするかを先に決める必要があります。 複数APIを束ねる仕組みでは、**最も制限の厳しいAPIが全体の設計を決めます。**ここを先に調べておくと、後戻りが減ります。 ## 最大の壁：Google Ads APIの複雑さと認証の永続化 技術的に最も重かったのがこれです。 **Google Ads APIの複雑さが最大の障壁でした。**加えて、実用化の鍵になるのが**OAuth認証の永続化（リフレッシュトークンの管理）**です。 定期実行の仕組みでは、誰も見ていない時間帯に認証が切れて止まる、という事態を避けなければなりません。トークンをどこに保持し、どう更新し続けるか。ここが設計の中心になります。 準備としてGoogle Ads MCC（マルチクライアントセンター）のアカウントを作成し、テスト環境を構築。Makeでデータ取得のプロトタイプも作りました。 ## 方針転換：Makeでの認証維持をやめる プロトタイプを作る中で見えたのは、**リモート環境（Make等）でのOAuth認証維持が煩雑だということ**でした。 そこで構成を変える判断をしています。 - **ローカルMCP接続**にする、または - **認証基盤を自前で持つ**（Vercel / Cloud Run などに構築する） ノーコードツールは組むのが速い反面、**認証の永続化のような「見えない部分の作り込み」が必要になると、かえって扱いにくくなります。**ここが分岐点でした。 ## 全自動を急がない、という判断 営業上の優先度変更と、認証の技術障壁。この2つが重なったため、**無理に全自動化を急がない方針に切り替えました。** 段階的な進め方はこうです。 1. **まずローカル環境で動くMCPとしてデータを取得する** 2. **レポート化は人間が行う** 3. 安定してきた工程から順に自動化していく **「データを取ってくる」ところと「定期実行で無人化する」ところは、難易度がまったく違います。**前者だけでも日々の巡回は減らせるので、そこから始めるという整理です。 ## よくある質問 ### なぜMakeでの自動化をやめたのですか？ **リモート環境でのOAuth認証の維持が煩雑だったためです。**定期実行では認証が切れると止まってしまうため、リフレッシュトークンの管理を含めた認証基盤を自前で持つか、ローカル接続にする方向へ切り替えました。 ### Clarityの1日10回制限は回避できますか？ 回避はできないため、**取得タイミングの最適化が必須です。**必要なときに都度叩く設計ではなく、決まった時刻に取得してキャッシュする前提で組む必要があります。 ### どのAPIが一番大変でしたか？ **Google Ads APIです。**API自体の複雑さに加え、OAuth認証の永続化が実用化の鍵になります。GA4は制限にも余裕があり、比較的扱いやすい部類でした。 ### 結局レポートは自動化できたのですか？ **全自動化は保留しています。**現時点では、ローカル環境で動くMCPとしてデータを取得し、レポート化は人間が行う段階です。認証基盤が整ってから、順次自動化を進める計画です。 ## まとめ - 複数の解析APIを束ねる際は、**最も制限の厳しいAPIが全体設計を決める**。Clarityは1日10回 - GA4は制限に余裕があり扱いやすいが、**Google Ads APIの複雑さが最大の障壁** - 実用化の鍵は**OAuth認証の永続化（リフレッシュトークン管理）** - リモート環境（Make等）での認証維持が煩雑なため、**ローカルMCPまたは自前の認証基盤**へ方針転換 - 全自動化を急がず、**まずデータ取得だけ自動化し、レポート化は人間が行う**段階から始める 定期実行の自動化は、作るところより「止まらずに動き続けること」が難しい領域です。認証まわりの設計を後回しにすると、あとで作り直すことになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のデータ活用と業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## NotebookLMで「生きたFAQ」を作る｜ソース更新に回答が追従する社内ナレッジ構築の検証 - URL: https://ai-katsu.jp/articles/notebooklm-knowledge-sharing - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-30T00:00:00+00:00 - Models: Gemini - Tools: NotebookLM - Tasks: ナレッジ活用・RAG, ツール検証 > アップロードした資料だけを参照するNotebookLMを、社内規定やFAQのようなハルシネーションが許されない用途で検証しました。Googleドキュメント連携によりソース更新に回答が自動追従する「生きたFAQ」を構築できた一方、画像非対応やワークスペースでの社外共有制限も判明。Difyとの使い分け基準もあわせてまとめています。 社内規定やFAQのように、**間違った答えが返ってきては困る情報**をAIに扱わせるのは難しい問題です。一般的なチャットAIは学習した知識から答えを組み立てるため、もっともらしい嘘（ハルシネーション）が混ざります。 NotebookLMは、**アップロードしたドキュメントだけを参照する「ソースグラウンドAI」**です。この性質が社内ナレッジ共有にどこまで使えるかを検証し、導入ガイドラインとしてまとめました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月〜9月（8/30〜9/1） | | 使用ツール | NotebookLM（無料版・エンタープライズ版） | | 解決したかった課題 | ハルシネーションが許されない情報の正確な抽出と、参照元明示によるファクトチェックの効率化 | | 最大の収穫 | ソース更新に回答が自動追従する**「生きたFAQ」**を構築できた | | 制約 | 画像ファイルを直接サポートしていない。ワークスペースアカウントでは社外共有に制限 | | 判定 | 完了（導入ガイドライン策定） | > 本記事は自社での検証記録です。回答精度の数値評価は行っていないため、正答率などの数値は掲載していません。 ## 結論：ソースが更新されると回答も追従する「生きたFAQ」 この検証で最も価値があったのがこれです。 **GoogleドキュメントやスライドとNotebookLMを連携させると、ソース側を更新したときに回答も自動で追従します。**社内規定を1箇所直せば、AIの答えもその日から変わる、という状態です。 従来のFAQ運用では、原本を直したあとにFAQページも直す、という二重管理が発生します。**更新漏れによって古い情報が残り続けるのが、この手の仕組みが形骸化する典型的な原因です。** ソースが単一で、そこを直せば全部が変わる。この構造が作れることが、NotebookLMを社内ナレッジに使う最大の理由になります。 ## 参照元が明示される安心感 NotebookLMは回答の根拠となった箇所を示します。**「その答えはどこに書いてあるのか」を即座に辿れるため、ファクトチェックが効率化されます。** 社内規定のように判断の根拠になる情報では、答えそのものより「どこに書いてあるか」が重要な場面があります。参照元が出るだけで、AIの回答を業務に使えるかどうかが変わります。 ## 制約1：画像は直接扱えない **現時点では画像ファイルを直接サポートしていません。** 図表が多い資料をそのまま投入しても、画像部分は参照されません。対応として、**Geminiで一度テキスト化してから投入するワークフロー**が必要になります。 手順書やマニュアルは図が多いので、この一手間は無視できません。導入前に、対象資料に画像がどれだけ含まれるかを確認しておくとよいでしょう。 ## 制約2：ワークスペースアカウントでは社外共有に制限 もう一つの実務上の壁です。**ワークスペースアカウントで作成したノートブックは、社外への共有に制限があります。** 対応方針は2つに整理しました。 - **閲覧権限をチャットのみに制限した共有リンクを使う** — ソース自体は見せず、質問への回答だけを提供する - **別の公開用ツールと切り分ける** — 社内向けと社外向けで仕組みを分ける 社内ナレッジとして使うぶんには問題ありませんが、**顧客向けのFAQをここで賄おうとすると詰まります。** ## 収穫：音声解説が最大40分まで拡張されていた 検証中に確認できた機能として、**音声解説機能が最大40分まで拡張されています。** 資料をポッドキャスト形式で聞き流せるため、**移動中に社内資料をインプットするという新しい学習スタイル**が成立します。読む時間が取れない資料を音声で流しておく、という使い方は想像以上に有効でした。 ## DifyとNotebookLMの使い分け 社内AI活用の相談でよく並べられる2つですが、今回の検証で判断基準を明確にしました。 | | NotebookLM | Dify | | --- | --- | --- | | コスト | 低い | 高い | | 学習負荷 | 低い（即効性がある） | 高い | | 向いている用途 | 資料を読ませて答えさせる | 特定のワークフロー自動化 | **判断軸は「特定のワークフロー自動化が必要かどうか」です。**ただ資料に基づいて答えてほしいだけならNotebookLM、処理の流れを組みたいならDify。この線引きで迷いがなくなりました。 ## よくある質問 ### ハルシネーションは起きませんか？ アップロードしたドキュメントのみを参照する設計のため、**一般的なチャットAIより起きにくい構造です。**加えて参照元が明示されるので、答えの根拠をその場で確認できます。ただし精度の数値評価は行っていません。 ### 無料版で足りますか？ 無料版は最大50ファイルまでです。**扱う資料の数によります。**今回は無料版とエンタープライズ版の制限を比較しましたが、社内の一部門で使う範囲であれば無料版から試すのが現実的です。 ### PDFやマニュアルをそのまま入れられますか？ PDFやGoogleドキュメント、音声ファイルはインポートできます。**ただし画像ファイルは直接サポートされていません。**図表が多い資料は、Geminiでテキスト化してから投入する必要があります。 ### 顧客向けFAQに使えますか？ **ワークスペースアカウントでは社外共有に制限があるため、そのままでは難しいです。**閲覧権限をチャットのみに絞った共有リンクを使うか、公開用は別ツールに切り分けてください。 ## まとめ - Googleドキュメント連携により、**ソース更新に回答が自動追従する「生きたFAQ」**を構築できる - 参照元が明示されるため、**ファクトチェックが効率化**される - **画像ファイルは直接扱えない。**Geminiでテキスト化してから投入する必要がある - ワークスペースアカウントでは**社外共有に制限**あり。顧客向け用途には向かない - 音声解説が最大40分まで拡張。資料をポッドキャスト形式でインプットできる - Difyとの使い分けは**「特定のワークフロー自動化が必要かどうか」**で判断する 社内ナレッジのAI活用では、賢さより「間違えないこと」と「更新され続けること」が効きます。今回はその両方を満たす構成が見つかった検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のナレッジ活用とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## AIにDB設計を任せると何が漏れるか｜Kiro×Supabaseで特定した「言われないと落とす機能」 - URL: https://ai-katsu.jp/articles/amazon-q-kiro-db-design - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-30T00:00:00+00:00 - Models: Amazon Q / Kiro - Tools: Supabase - Tasks: 開発・エンジニアリング, ツール検証 > Amazon Q／KiroとSupabaseで、運用に耐える詳細設計をAIがどこまで網羅できるか検証しました。操作ログ・ログアウト・パスワード再設定といった運用必須機能が指示なしでは漏れる傾向を特定。DB設計は実装前に表形式の設計書として出力させ人間が目視チェックする、という工程を確立した記録です。 前回の検証で、Amazon Q／Kiroが設計の「骨組み」を高速に作れることは確認できました。次に確かめたかったのは、**実際のプロダクト運用に耐える詳細設計——DB正規化や非機能要件まで、どこまで網羅できるか**です。 結論として、**AIが指示なしでは落としがちな必須機能がはっきり特定できました。**そして、DB設計をAIに任せる際の工程も定まりました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月〜9月（8/30〜9/1） | | 使用ツール | Amazon Q／Kiro / Cursor（Claude 3.5 Sonnet・Grok-1）/ Supabase / ChatGPT | | やりたかったこと | DB正規化や非機能要件など、運用に耐える詳細設計をAIがどこまで網羅できるか検証する | | 特定できた課題 | **Kiro単体では「操作ログ」「ログアウト」など運用必須機能が漏れる傾向** | | 確立した工程 | DB設計は実装前に**「表形式の設計書」としてAIに出力させ、人間が目視チェック**する | | 判定 | 完了（開発フローの再定義） | > 本記事は自社での検証記録です。パフォーマンスの実測値は掲載していません。 ## 結論：AIは「言われなかったこと」を落とす この検証で最も価値のある発見がこれです。 **Kiro単体で設計させると、「操作ログ」「ログアウト機能」「パスワード再設定」といった運用必須機能が漏れる傾向がありました。** これらは、機能要件として明示されることが少ない一方、実運用では必ず必要になるものです。人間のエンジニアであれば経験から補いますが、AIは指示されなければ出力に含めません。 対応として、**こうした機能を事前に要件定義書に含めておくプロセスの重要性**を確認しました。AIの網羅性に期待するのではなく、落ちやすい項目をこちらから渡す、という考え方です。 > 裏を返せば、**「AIが落としがちな項目リスト」を一度作っておけば、以降の案件で使い回せます。**今回の検証は、そのリストの起点になりました。 ## DB設計の進め方：実装前に表形式で出させる 正規化やインデックス設定といった、DB設計の深い部分をどう扱うか。ここで確立した工程が次のものです。 1. **実装前に「表形式の設計書」としてAIに出力させる** 2. **人間が目視でチェックする** 3. 問題がなければ実装に進む **いきなりコードを書かせないことがポイントです。**DB設計の誤りは、実装が進むほど修正コストが跳ね上がります。表の形で出させれば、正規化の妥当性やインデックスの過不足を短時間で確認できます。 この「設計書を挟む」工程が、今回の結論として最適解でした。 ## 検証の進め方 実際には、次の順で進めています。 1. **ChatGPTで機能・非機能要件を詳細化**し、それをKiroに投入する 2. **バックエンドをSupabaseに統一**し、UUIDによるユーザー管理を実装 3. **パフォーマンス基準を提示**し、実務レベルのレスポンスを要求する 要件定義の段階を別のAIで厚くしてからKiroに渡す、という二段構えです。**Kiroに要件定義まで丸ごと任せると、前述の「落ちやすい項目」が漏れます。** ## 実装フェーズ：Kiroのspecsを起点にCursorで対話実装 実装については、前回確立した分担を踏襲しています。 **Kiroが生成した `specs` をベースに、Cursorで「バイブコーディング（対話型実装）」を行う**形です。これにより、実装速度を維持しつつ、柔軟な手直しができます。 設計はKiro、実装はCursor、判断は人間。この三層が今回も有効に機能しました。 ## よくある質問 ### AIにDB設計を任せて大丈夫ですか？ **そのまま実装させるのは避けてください。**正規化やインデックス設定といった深い部分は、実装前に表形式の設計書として出力させ、人間が目視でチェックする工程を挟むのが最適解でした。 ### どんな機能が漏れやすいですか？ 今回特定できたのは**操作ログ、ログアウト機能、パスワード再設定**です。いずれも運用では必須ですが、機能要件として明示されにくいものです。事前に要件定義書へ含めておくことをおすすめします。 ### Kiroだけで要件定義から実装まで完結しますか？ **完結しません。**要件定義はChatGPTなどで詳細化してからKiroに投入し、実装はCursorで対話しながら進める、という分担が有効でした。工程ごとに得意なツールを割り当てるほうが結果的に速く進みます。 ## まとめ - **Kiro単体では「操作ログ」「ログアウト」「パスワード再設定」など運用必須機能が漏れる**傾向を特定 - 対策は**事前に要件定義書へ含めておくこと**。AIの網羅性に期待しない - DB設計は**実装前に「表形式の設計書」として出力させ、人間が目視チェック**する工程が最適解 - 要件定義はChatGPTで詳細化 → Kiroに投入 → Cursorで対話実装、という三段構え - バックエンドはSupabaseに統一し、UUIDでユーザー管理 AIに設計を任せる際は「何を出力させるか」より「何が落ちるか」を把握しているほうが役に立ちます。落ちる項目が分かっていれば、先に渡せば済むからです。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発内製化とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## LINEの投稿をExcelに自動蓄積する｜Make連携で押さえるべき3つの設計判断 - URL: https://ai-katsu.jp/articles/line-message-api-make - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-28T00:00:00+00:00 - Tools: LINE, Make, Excel - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: バックオフィス > LINE Message APIとMakeを連携し、公式アカウントへの投稿が数秒でExcelに追加されるフローを構築しました。Parse JSONを使わずWebhookのサンプルキャプチャで完結させたメンテナンス性重視の設計、変数マッピングでのエラー防止、SharePointではなくOneDriveを選ぶ理由など、実運用で効く判断をまとめています。 LINE公式アカウントに届いた投稿を、そのままExcelに蓄積したい——問い合わせ管理や日報の回収など、この形のニーズは頻繁に出てきます。 LINE Message APIとMakeを繋いで、**LINEへの投稿が数秒でOneDrive上のExcelに追加される一気通貫のフロー**を構築しました。構築の過程で、メンテナンス性を上げるための設計判断と、自動化が止まりやすい落とし穴が見つかったので共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月28日 | | 使用ツール | LINE Message API / Make（旧Integromat）/ Microsoft 365 Excel | | やりたかったこと | LINE公式アカウントへの投稿を、リアルタイムかつ正確にExcelへ蓄積する | | 結論 | 投稿から**数秒でOneDrive上のExcelに追加される**フローを構築。汎用パターンとして確立 | | 設計判断 | 「Parse JSON」モジュールを使わず、Webhookの「サンプルキャプチャ」機能だけで構造化を完結させた | | 注意点 | SharePoint上のExcelは認証問題が起きやすい。**OneDrive格納を標準とする** | > 本記事は自社での検証記録です。工数削減の定量測定は行っていないため、数値は掲載していません。 ## 結論：Parse JSONを使わないほうがメンテナンスしやすい この検証で最も実務的な学びがこれです。 LINEのWebhookから届くデータはJSON形式です。Makeには「Parse JSON」というモジュールがあり、これを挟んで構造化するのが一見すると素直な作りに見えます。 しかし今回は、**Parse JSONを使わず、Webhookの「サンプルキャプチャ」機能だけで構造化を完結させる方式を採用しました。**理由はメンテナンス性です。モジュールが1つ減るぶん、フローの見通しが良くなり、後から手を入れやすくなります。 ## 構築したフロー ``` LINE公式アカウント（ユーザーが投稿） ↓ Webhook Make（サンプルキャプチャで構造化） ↓ Microsoft 365 Excel（OneDrive上）に行を追加 ``` 投稿から数秒でExcelに反映されます。間に自作のサーバーを挟む必要はありません。 ## 手順で外せないポイント：先にテスト投稿する Makeを扱ううえで重要な手順を、あらためて確認しました。 **一度テスト投稿を行って「サンプル取得」をさせないと、下流のモジュールでフィールド（変数）として選択できません。** Makeは実際に届いたデータの構造を見て、そこから選べる変数を組み立てます。つまり**データが一度も流れていない状態では、次のモジュールで何も選べない**ということです。フローを組む順番として、ここは飛ばせません。 ### 変数は手入力せず「紫チップ」で挿す もう一つの実務的なコツです。**複雑なJSONであっても、Make上の「紫チップ（変数）」を使えば直感的にマッピングできます。** 変数名を手で打ち込むと、綴りの間違いや階層の取り違えでエラーになります。**手入力を避けることが、そのままエラー防止になります。** ## つまずいたこと：SharePoint上のExcelは止まりやすい 実運用に向けて重要な発見がこれです。 **SharePoint上のExcelファイルを対象にすると、認証問題が発生しやすく、自動化が止まるリスクがあります。** 自動化は「止まらないこと」が価値なので、認証まわりで不安定になる構成は避けたいところです。対応として、**個人用またはBusiness用のOneDriveに格納されたExcelファイルを標準とする**設定に変更しました。 同じMicrosoft 365のExcelでも、どこに置くかで安定性が変わります。**ファイルの置き場所は、自動化の設計項目のひとつです。** ## 応用できる範囲 今回作ったものは、抽象化すると**「LINEに届いた情報を表に蓄積する仕組み」**です。入口と出口を差し替えれば、幅広く応用できます。 - 問い合わせ内容の一次受けと記録 - 現場からの日報・報告の回収 - アンケートや申し込みの受付 次の展開としては、Lステップのようなより高度なLINEマーケティングツールとの連携可能性を検証する予定です。 ## よくある質問 ### なぜParse JSONを使わないのですか？ **メンテナンス性を高めるためです。**Webhookのサンプルキャプチャ機能だけで構造化が完結するため、モジュールを1つ減らせます。フローがシンプルなほど、後から手を入れやすくなります。 ### Excelはどこに置くべきですか？ **OneDrive（個人用またはBusiness用）を推奨します。**SharePoint上のファイルは認証問題が発生しやすく、自動化が止まるリスクがあります。 ### 変数が選択できません **一度テスト投稿を行って、Webhookに「サンプル取得」をさせてください。**データが流れていない状態では、下流のモジュールでフィールドを選択できません。Makeを使う際の基本手順です。 ### どのくらいで反映されますか？ LINEへの投稿から**数秒でExcelに追加されます。**ただし正確なレイテンシの測定は行っていません。 ## まとめ - LINE Message API × Make × Excel で、**投稿から数秒でExcelに蓄積される**フローを構築 - **Parse JSONを使わず、Webhookのサンプルキャプチャだけで構造化**。メンテナンス性を優先した判断 - Makeでは**先にテスト投稿してサンプル取得させないと、下流で変数を選べない** - 変数は手入力せず**紫チップでマッピング**することがエラー防止になる - **SharePointではなくOneDriveにExcelを置く**。認証問題で自動化が止まるのを避けるため 自動化は作った直後より、止まらずに回り続けるかどうかで評価が決まります。今回はその観点での設計判断が多く得られた検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Amazon Q／Kiroで設計フェーズを数分に短縮する｜tasks.mdの具体性とバイブコーディングの必要性 - URL: https://ai-katsu.jp/articles/amazon-q-kiro-dev-acceleration - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-26T00:00:00+00:00 - Models: Amazon Q / Kiro - Tasks: 開発・エンジニアリング, ツール検証 > 要件定義から設計・実装タスク生成までをAIがどこまで担えるか、Amazon Q／Kiroで検証しました。生成されるtasks.md（実装手順書）は極めて具体的で実装時の迷いがなくなる一方、出力コードにはUIバグやDB接続エラーが発生。仕様書＝Kiro／実装＝Cursorというハイブリッドな役割分担に至った経緯をまとめています。 要件定義から設計、実装タスクの洗い出しまで。エンジニアが数日かけるこのフェーズを、AIがどこまで一貫して担えるのか。ウェイトリストを通過したAmazon Q／Kiroで検証しました。 結果として、**Kiroが生成する実装手順書（tasks.md）の具体性は驚異的で、実装時の迷いがなくなるという体験**が得られました。一方で、出力されたコードをそのまま動かせるわけではありません。実務でどう組み込むかまで含めて共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月（8/26〜8/28） | | 使用ツール | Amazon Q／Kiro（AWS Builder ID）／ Cursor / SQLite | | やりたかったこと | 要件定義から設計・実装タスク生成までをAIがどこまで一貫して担えるか確認する | | 題材 | 食事管理アプリ（既存サービスを模した構成） | | 結論 | **設計〜環境構築フェーズで劇的な工数削減を達成。**ただしコードは人間の即時修正が前提 | | 確立した役割分担 | 仕様書作成＝Kiro／コード実装＝Cursor（Rules適用）のハイブリッド | > 本記事は自社での検証記録です。削減時間の実測は行っていないため、具体的な数値は掲載していません。 ## 結論：tasks.md の具体性が体験を変える この検証で最も印象的だったのがこれです。 **Kiroが生成する `tasks.md`（実装手順書）が極めて具体的で、実装時の迷いが一切なくなります。**「次に何をすればいいか」を考える時間が消える、という感覚です。 設計フェーズの実務では、何を作るかは決まっていても「どの順で手をつけるか」で止まることがよくあります。そこが埋まっているだけで、着手までの摩擦が大きく下がります。 加えて、**個人情報保護法やGDPR対応といった法的ポリシーを考慮した設計**が出力に含まれる点も、実務では効いてきます。後から気づいて作り直す、という手戻りを減らせます。 ## つまずいたこと：ポン出しのコードは動かない 一方で、生成されたコードをそのまま動かそうとすると壁があります。 **UIのバグや、SQLiteの接続エラーが発生しました。**設計の質が高いこととコードがそのまま動くことは、別の話です。 ここで必要になるのが、**AIの「提案」を人間が即座に修正していくスキル**です。今回はこれを「バイブコーディング（対話型実装）」と呼んで運用しています。エラーを見て、原因を判断し、その場で直す。この往復ができるかどうかで、生産性が大きく変わります。 **AIに任せれば誰でも実装できる、という話ではありません。**むしろ判断できる人が使うほど速くなるツールです。 ## 確立した役割分担：Kiroで仕様、Cursorで実装 検証を通じて、次のハイブリッドな分担に落ち着きました。 | フェーズ | 担当 | 成果物 | | --- | --- | --- | | 要件定義・設計 | Kiro | スペックファイル、tasks.md | | コード実装 | Cursor（Rules適用） | 実装コード | | エラー対応・修正 | 人間（バイブコーディング） | 動く状態 | **Kiroの強みは設計の網羅性、Cursorの強みは対話しながらの実装です。**どちらか一方で完結させようとせず、得意な工程を割り当てたほうが速く進みます。 ## よくある質問 ### Kiroだけで開発は完結しますか？ **完結しません。**設計と実装手順書の生成は非常に強力ですが、出力されたコードにはUIのバグやDB接続エラーが発生しました。実装フェーズは別のツールと人間の判断を組み合わせる前提で考えてください。 ### エンジニアでなくても使えますか？ **難しいというのが率直な評価です。**AIの提案を即座に修正する「バイブコーディング」のスキルが必須になります。エラーの原因を判断できることが前提です。 ### どのくらい工数が削減できましたか？ **この検証では実測を行っていないため、具体的な数値はお答えできません。**「設計〜環境構築のフェーズで劇的に短縮された」という定性的な評価にとどまります。 ### 法令対応も自動で考慮されますか？ 個人情報保護法やGDPR対応など、法的ポリシーを考慮した設計が出力に含まれました。**ただし出力をそのまま採用してよいという意味ではなく、内容の確認は必要です。**気づきを与えてくれる、という位置づけで捉えるのが安全です。 ## まとめ - Kiroが生成する**tasks.md の具体性が高く、実装時の迷いがなくなる** - 個人情報保護法やGDPR対応など、**法的ポリシーを考慮した設計**が出力に含まれる - ただし**ポン出しのコードはそのまま動かない**。UIバグやDB接続エラーが発生した - AIの提案を即座に修正する**「バイブコーディング」のスキルが必須** - 実務では**仕様書＝Kiro／実装＝Cursor**のハイブリッドな役割分担が有効 AI開発支援ツールは「誰でも作れるようになる」ものではなく「判断できる人がより速くなる」ものです。今回の検証でも、その傾向がはっきり出ました。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発内製化とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## オンライン会議のリアルタイム翻訳ツール比較｜字幕は実用レベル、音声吹き替えはまだ早い - URL: https://ai-katsu.jp/articles/realtime-voice-subtitle-translation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-23T00:00:00+00:00 - Tools: Google Workspace - Tasks: 音声・翻訳・文字起こし, ツール検証 > 海外クライアントとの会議で使えるリアルタイム翻訳の最適解を探し、Google Meet・Teamsの標準機能からVoicePing・オンヤク・JotMeまで横断比較しました。字幕翻訳はGoogle Meetの標準機能で実用レベルに達している一方、音声吹き替えは各社ベータ段階で数秒の遅延あり。自作せずプラットフォームの進化を待つという判断に至った理由をまとめています。 海外クライアントとのオンライン会議で言語の壁をどう越えるか。同時通訳者を立てずに、自然なスピードで意思疎通できる環境を作れないか——この問いから、リアルタイム翻訳ツールを横断的に比較しました。 結論は、**字幕翻訳はすでに実用レベルに達している一方、音声の吹き替えはまだ待つべき**というものです。そして現時点では、自作するよりプラットフォームの進化を待つほうがコスト対効果が高い、という判断に至りました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月（8/23〜8/29） | | 比較対象 | Google Meet / Teams の標準機能、VoicePing、オンヤク、JotMe ほか | | 比較の観点 | 字幕翻訳と音声翻訳の両面。日本語対応状況・遅延時間・コスト（有料プランの要否） | | 結論（字幕） | **Google Meetの標準機能（Business Standard以上）で実用レベル** | | 結論（音声） | 各社とも開発・ベータ版段階。**数秒の遅延と不自然さが残る** | | 判定 | 検証中（継続調査）。現時点では自作せず、プラットフォームの進化を待つ | > 本記事は自社での検証記録です。遅延時間は「数秒」という定性的な把握にとどまり、ミリ秒単位の測定は行っていないため、具体的な数値は掲載していません。 ## 結論：字幕は使える。音声はまだ早い この検証で最もはっきり分かれたのが、**字幕翻訳（テキスト表示）と音声翻訳（吹き替え）の成熟度の差**でした。 ### 字幕翻訳：実用レベル **Google Meetの標準機能（Business Standard以上）で、すでに実用レベルに達しています。**外部ツールを追加導入しなくても、契約プランの範囲で会議に字幕翻訳を載せられます。 ### 音声翻訳：まだベータ 一方、**日本語から外国語への「音声」吹き替えは、各社とも開発・ベータ版の段階です。**数秒の遅延と、聞いていて不自然さが残る状態でした。 会話のテンポが命のオンライン会議で数秒ずれると、相手の発言に被せてしまうなど、かえって進行の妨げになります。**「動く」ことと「会議で使える」ことの間には、まだ距離があります。** ## 実務での提案は「音声」ではなく「即時表示」から この結果を受けて、社内の提案方針を変えました。 **「リアルタイムの音声出力」に固執せず、まずは「翻訳テキストの即時表示」で合意形成を図る**——これを標準の提案としています。 音声出力が必須という要件になると、技術的なハードルが一気に上がります。**本当に音声が必要なのか、それとも「相手の言っていることが分かればよい」のかを切り分けると、多くのケースは字幕で足ります。** 要件の詰め方ひとつで、実現可能性もコストも大きく変わる領域です。 ## 精度の限界：専門用語とジョーク 翻訳精度そのものにも制約があります。**専門用語やジョークの翻訳には限界がありました。** 業界特有の言い回しや、文脈に依存した冗談は、そのまま訳すと意味が通じません。会議の場では、この取りこぼしが認識のズレとして後から効いてきます。 対策として、**補助的にテキスト（ログ）を残せるツールとの併用が必須**と整理しました。その場で理解しきれなくても、後からログを確認して補正できる状態を作っておく、という考え方です。 ## 自作しないという判断 この領域は各社が開発競争をしている真っ最中です。だからこそ、**現時点では「自作」よりも、プラットフォーム（Google / Microsoft）の進化を待つほうがコスト対効果が高い**と判断しました。 自前で翻訳の仕組みを組むと、作った瞬間から保守が始まります。その間にも標準機能は改善されていきます。**標準機能で足りるなら、そちらに乗ったほうが長期的に安く済みます。** ## よくある質問 ### 結局どのツールを使えばいいですか？ 字幕翻訳が目的なら、**Google Meetの標準機能（Business Standard以上）から試すことをおすすめします。**すでに実用レベルで、追加のツール導入も不要です。音声吹き替えが必須の場合は、現時点で満足できる選択肢が見つかりませんでした。 ### 音声の吹き替えはどのくらい遅れますか？ **数秒の遅延があります。**この検証ではミリ秒単位の測定は行っていないため、正確な数値はお答えできません。会話のテンポを保つには厳しい、という体感的な評価です。 ### 専門用語が多い会議でも使えますか？ **翻訳精度に限界があります。**専門用語やジョークは取りこぼしが発生します。テキストログを残せるツールを併用し、後から確認できる状態にしておくことをおすすめします。 ### 自社で翻訳の仕組みを作るべきですか？ **現時点ではおすすめしません。**各社が開発競争をしている領域で、標準機能の進化が速いためです。自作すると保守が発生する一方、待っていれば標準機能が改善されます。 ## まとめ - **字幕翻訳はGoogle Meetの標準機能（Business Standard以上）で実用レベル**に達している - **音声吹き替えは各社ベータ段階**。数秒の遅延と不自然さが残り、会議での実用は厳しい - 提案時は**「音声出力」に固執せず「翻訳テキストの即時表示」で合意形成**を図るのを標準とした - 専門用語やジョークの精度には限界があるため、**テキストログを残すツールとの併用が必須** - 現時点では**自作よりプラットフォームの進化を待つほうがコスト対効果が高い** 新しい技術の導入では「作れるか」より「待つべきか」の判断が効く場面があります。動きの速い領域ほど、自作の保守コストが重くのしかかります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 不定休に対応するガントチャートをExcelで作る｜ChatGPTと7回作り直して確立した指示の型 - URL: https://ai-katsu.jp/articles/ai-gantt-chart - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-16T00:00:00+00:00 - Models: ChatGPT - Tools: Excel - Tasks: 業務自動化・ワークフロー, ツール検証 > 土日休み固定のテンプレートでは使えない建設・飲食などの現場向けに、不定休・複数従業員・親子タスク連動・進捗オーバーレイを備えたExcelガントチャートをChatGPTと構築しました。稼働日管理シートの分離やAGGREGATE関数による親子連動の実装に加え、複雑なシートをAIに作らせるための「前提を固定して段階的に指示する」型を確立した記録です。 Excelのガントチャートテンプレートは世の中に無数にありますが、その多くは**土日休みが前提**です。建設や飲食のように不定休で動く現場では、この時点で使えません。現場ごとの稼働形態に合わせようとすると、結局は自作することになります。 この検証では、ChatGPTとの対話を通じて**不定休・複数従業員・親子タスクに対応し、進捗率でセルの色が変わるガントチャート**をExcelで構築しました。v1からv7まで段階的に作り込む過程で、複雑なExcelシートをAIに作らせるための指示の型も確立しています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月（8/16〜8/22） | | 使用ツール | Microsoft Excel（Mac版 16.98基準）/ ChatGPT | | 解決したかった課題 | 非営業日（不定休）の動的な扱い、親子タスクの連動、進捗率の視覚化を同時に満たすExcelベースの管理ツールを作る | | 成果物 | 進捗オーバーレイ付きガントチャート（v7まで多段階で開発） | | 使用した関数 | INDEX / MATCH / AGGREGATE（XLOOKUP等の新関数は使わない） | | 判定 | 完了（運用ロードマップ確立） | > 本記事は自社での検証記録です。作成時間の短縮率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：一気に作らせず、前提を固定して段階的に指示する 複雑なExcelシートをAIに作らせるうえで、最も効いた原則がこれです。 **「こういうガントチャートを作って」と一度に投げても、望むものは出てきません。**前提条件を固定した上で、段階的に指示を積み上げていく必要があります。今回はv1からv7まで、対話を重ねながら関数のデバッグを繰り返して完成させました。 この進め方を**独自の指示テンプレートとして確立できたこと**が、成果物そのものと並ぶ収穫です。同じ手順で他の複雑なシートも作れます。 ## 作ったもの ### 1\. 不定休に対応する「稼働日管理シート」の分離 建設・飲食など**業界ごとに違う稼働状況に対応させるため、稼働日を管理するシートを本体から分離しました。**フラグで管理する設計にすることで、現場ごとの休日パターンを柔軟に反映できます。 土日固定のテンプレートが使えない、という最初の課題はここで解消しています。 ### 2\. 親子タスクの連動 当初は親タスクだけの管理で進めていましたが、**現場では子タスクの進捗が親に反映されるUIが必須**だと分かりました。 対応として、**親子関係を定義するキー（担当者◆親タスク）を設定し、AGGREGATE関数で子タスクの開始日・終了日の最小値と最大値を自動取得するロジック**を実装しています。子を動かせば親の期間が自動で追随します。 ### 3\. 進捗オーバーレイ 進捗率に応じてセルの色が変化する仕組みです。バーを見るだけで、どのタスクがどこまで進んでいるかが分かります。 ## あえて新関数を使わなかった理由 技術的な判断として重要だったのが、**XLOOKUPなどの新しい関数を使わず、INDEX/MATCHやAGGREGATEといった旧来の関数だけでロジックを組んだこと**です。 理由はExcelのバージョン差異です。今回はMac版16.98を基準にしていますが、**社内で広く使うツールである以上、環境によって動かないという事態は避ける必要があります。**新関数は書きやすい反面、使える環境が限られます。 **「自分の環境で動く」ではなく「配った先で動く」を優先した**結果、堅牢な旧関数のみという制約を自分に課しました。 ## つまずいたこと：GPTsでの量産は難しかった 完成した設計をGPTsに載せて量産化を試みましたが、**プルダウンの欠落や関数の不適用が多く発生しました。** 結果として、**最終的な仕上げには依然として人間のチューニングが必要**という結論です。設計をテンプレート化すれば誰でも量産できる、という状態には至りませんでした。 ## 正直な比較：スプレッドシートのほうが見やすい 検証の中で気づいた点として、率直に書いておきます。 **Googleスプレッドシートのタイムライン機能に条件付き書式を適用したほうが、Excel式のガントチャートよりも視認性の高いものが作れます。** 世間で「リッチなUI」と評されるガントチャートは、ブラウザやネイティブアプリで動いているものがほとんどです。共通しているのは**マークアップが使える環境である**という点でした。Excelのセルで表現できる範囲には、構造的な限界があります。 それでもExcelで作る意味があるのは、**現場がすでにExcelで動いている場合**です。新しいツールの導入は、機能の優劣とは別の話になります。 ## よくある質問 ### 不定休にはどうやって対応していますか？ **稼働日を管理する専用シートを本体から分離し、フラグで管理する設計にしています。**これにより、建設・飲食など業界ごとに異なる稼働形態を反映できます。 ### なぜXLOOKUPを使わないのですか？ **Excelのバージョン差異を考慮したためです。**社内で広く使うツールなので、環境によって動かないリスクを避けました。INDEX/MATCHやAGGREGATEといった旧来の関数のみでロジックを組んでいます。 ### ChatGPTに丸投げで作れますか？ **作れません。**一気に作らせるのではなく、前提を固定して段階的に指示を出す必要があります。今回もv1からv7まで、関数のデバッグを繰り返しながら仕上げました。GPTsでの量産化も試みましたが、最終的な仕上げには人間のチューニングが必要でした。 ### Excelではなくスプレッドシートを使うべきですか？ **視認性だけで言えば、Googleスプレッドシートのタイムライン機能のほうが見やすいものが作れます。**ただし現場がすでにExcelで動いているなら、そこに合わせる判断も妥当です。ツール選定は機能の優劣だけでは決まりません。 ## まとめ - 土日固定のテンプレートでは対応できない**不定休の現場向けに、Excelでガントチャートを構築** - **稼働日管理シートを分離**してフラグ管理にすることで、業界ごとの稼働形態に対応 - 親子タスクの連動は**キー設定＋AGGREGATE関数**で実装。子の進捗が親に反映される - **バージョン差異を避けるため、あえて旧関数のみ**で構築。配った先で動くことを優先 - 最大の収穫は**「前提を固定して段階的に指示する」というAIへの指示テンプレートの確立** - 視認性ではスプレッドシートのタイムライン機能に分があるのも事実 AIに複雑なものを作らせるときは、指示の出し方そのものが技術になります。今回はガントチャートを題材に、その型を作った検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務効率化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Power AutomateのCopilotはどこまで使えるか｜「完成品」ではなく「助手」として使う - URL: https://ai-katsu.jp/articles/power-automate-copilot - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-09T00:00:00+00:00 - Models: Microsoft Copilot - Tools: Power Automate - Tasks: 業務自動化・ワークフロー, ツール検証 > Power AutomateのCopilot機能で定型業務の自動化がどこまで効率化できるかを検証しました。複雑な条件分岐を含むフローの自動生成には限界がある一方、ツールの接続設定や基礎的な使い方の習得には有効。「完成品を作るツール」ではなく「パーツの組み合わせを提案する助手」と捉え直すことで実用的になった経緯をまとめています。 Power AutomateにはCopilotが搭載されており、「こういう自動化がしたい」と自然言語で伝えるとフローを生成してくれます。Microsoft 365をすでに使っている企業にとっては、追加投資なしで試せる自動化の入口です。 実務でどこまで使えるのかを検証したところ、**「完成品を作らせる」使い方では期待に届かない一方、「助手として使う」なら十分に有効**という結論になりました。この捉え方の切り替えが、今回の一番の収穫です。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月（8/9〜8/15） | | 使用ツール | Power Automate + Copilot for Power Automate | | やりたかったこと | Microsoftエコシステム内でのCopilotの実用性を確認し、定型業務の自動化をどこまで効率化できるか見極める | | 結論 | **複雑な自動化における実用性は現時点では低い。**一方、ツールの接続設定や基礎的な使い方の習得には有効 | | 捉え方の転換 | 「完成品を作るツール」ではなく「パーツの組み合わせを提案する助手」として使う | | 判定 | 完了（手法の確立） | > 本記事は自社での検証記録です。構築工数の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：Copilotは「助手」であって「代行者」ではない 検証を通じて最も重要だった発見がこれです。 **Copilotを「完成品を作るツール」として期待すると、実用性は低いと感じます。**複雑な条件分岐や、実業務に即した深いフローの自動生成には限界がありました。指示どおりのものが一発で出てくることはありません。 しかし、**「フローを構成するパーツの組み合わせを提案してくれる助手」として捉えると、評価が変わります。**この捉え方に切り替えることで、効率的な構築ができるようになりました。 同じツールでも、期待値の置き方で使えるかどうかが決まる——という典型的な例です。 ## できたこと：接続設定と基礎習得 **各種ツールの接続設定や、基礎的な使い方の習得については有効でした。** Power Automateは接続できるサービスが非常に多く、「このサービスと繋ぐにはどの設定が必要か」を調べる工程が発生します。Copilotはここを埋めてくれます。ドキュメントを探すより、聞いたほうが早い場面が多くありました。 **特にPower Automateを使い始めたばかりの段階では、学習の伴走役として機能します。**「まず何ができるのか」を掴むまでの時間が短縮されます。 ## できなかったこと：複雑なフローの自動生成 一方で、**複雑な条件分岐や、実業務に即した深いフローの自動生成には限界がありました。** 実務の自動化は、たいてい例外処理の塊です。「この条件のときだけ別のルートに流す」「この項目が空なら処理を止める」といった分岐が積み重なります。こうした業務固有の要件は、自然言語の指示から汲み取ることが難しい領域です。 結果として、**Copilotが出したフローをそのまま本番投入できる場面はほとんどありませんでした。** ## 実務での進め方 この検証を踏まえて、次のアプローチを採ることにしました。 1. **小さなパーツ（接続例）をCopilotで作り、検証する** — サービスAとサービスBを繋ぐ最小構成をまず動かす 2. **検証済みのパーツを組み合わせる** — 動くと分かっている部品を積み上げる 3. **具体的な業務事例に落とし込む** — 例外処理や条件分岐は人が設計する **「一発で完成形を出させる」のではなく「動く部品を集めて自分で組む」という進め方です。**Copilotの得意な範囲だけを使う形になります。 ## よくある質問 ### Copilotだけで業務フローは作れますか？ **複雑な業務フローは難しいというのが検証結果です。**条件分岐が多い実務レベルのフローでは、人による設計が必要になります。単純な接続や定型的な処理であれば、Copilotの出力をベースにできます。 ### Power Automateの初心者でも使えますか？ むしろ初心者に向いています。**接続設定や基礎的な使い方の習得には有効でした。**ドキュメントを探す代わりに聞ける、という使い方が学習コストを下げます。 ### どのくらい工数が減りますか？ **この検証では定量測定を行っていないため、数値はお答えできません。**「複雑な自動化では実用性が低い」「接続設定や基礎習得には有効」という定性的な評価にとどまります。 ## まとめ - Power AutomateのCopilotは、**複雑な自動化の完成品を作らせる用途では実用性が低い** - 一方、**ツールの接続設定や基礎的な使い方の習得には有効** - 捉え方を**「完成品を作るツール」から「パーツの組み合わせを提案する助手」に切り替える**と、効率的に使える - 実務では、検証済みの小さなパーツを組み合わせて業務事例に落とし込むアプローチが現実的 AI機能の評価では「期待どおりに動かない＝使えない」と結論づけがちですが、期待の置き方を変えると使いどころが見えることがあります。今回はその調整をした検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 音声会話AIは20分で作れる｜ElevenLabsで音声エージェントを構築して見えた精度とコストの壁 - URL: https://ai-katsu.jp/articles/elevenlabs-voice-agent - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-09T00:00:00+00:00 - Models: Gemini - Tools: ElevenLabs - Tasks: 音声・翻訳・文字起こし, ツール検証 > ElevenLabs Conversational AIで音声会話エージェントを作り、HP埋め込みまで検証しました。基本形の構築は約20分と短時間で完了した一方、Gemini 2.0 Flashでは会話の成立に難があり、トークン消費と接続時間の両方が効くコスト構造も判明。商用利用の判断材料をまとめています。 チャットボットは非同期のやりとりです。テキストを打って、返事を待つ。これに対して音声会話AIは、その場で会話が成立します。この体験の違いが商用で意味を持つのか——ホームページへの埋め込みを想定して検証しました。 結果として、**音声エージェントの基本形はわずか20分で構築できました。**ただし会話の精度はモデル選定に強く依存し、コスト面の懸念も残っています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月（8/9〜8/15） | | 使用ツール | ElevenLabs Conversational AI / Gemini 2.0 Flash | | やりたかったこと | 音声会話AIの商用利用（HP埋め込みなど）の可能性を探る | | 構築時間 | **約20分**で音声エージェントの基本形を構築 | | 結論 | プロトタイプ作成済み。**条件付きで導入可** | | 課題 | Gemini 2.0 Flashでは正しい会話の成立に難あり。API利用費用の高騰リスク | > 本記事は自社での検証記録です。会話精度の数値評価やコスト試算は実施していないため、具体的な数値は掲載していません。 ## 結論：作るのは速い。難しいのはモデル選定とコスト **ElevenLabsのConversational AIを使えば、音声エージェントの基本形は20分程度で組み上がります。**ホームページへの埋め込み表示まで含めて、プロトタイプとして動く状態には短時間で到達できました。 つまり、**この領域の技術的なハードルはすでに低い**ということです。試すだけなら気軽に始められます。 実用化の判断で効いてくるのは、その先の2点でした。会話の品質と、費用です。 ## 会話精度はモデル選定で大きく変わる 今回はモデルに **Gemini 2.0 Flash** を使いましたが、**正しい会話の成立に難がありました。** 音声会話は、テキストチャットよりも会話の破綻が目立ちます。相手が話し終わるのを待って、意図を汲んで、適切な長さで返す——このリズムが崩れると、体験として成立しません。 **OpenAIやGeminiの別バージョンを使えば、精度が大きく変わる可能性があります。**今回の検証では1つのモデルしか試していないため、「ElevenLabsの会話品質が低い」という結論ではありません。**プラットフォームの評価とモデルの評価を分けて考える必要があります。** ## コスト：トークンと接続時間の両方がかかる 実用化にあたっての懸念として挙がったのが、**API利用費用の高騰リスク**です。 音声会話は、テキストのやりとりと課金構造が違います。トークン消費に加えて、**接続している時間そのものがコストになります。**会話が長引くほど、あるいは同時接続が増えるほど費用が伸びる構造です。 ホームページに埋め込んで不特定多数に開放する場合、**アクセス数が読めないぶんコストも読めません。**実用化にあたっては、トークン消費と接続時間の両方を踏まえたコスト試算が必須になります。 ## 面白かったところ：キャラクターに声を与える 実務的な評価とは別に、可能性を感じた使い方がありました。 **キャラクターに音声を吹き込ませ、双方向の会話を楽しむエンタメ的な活用です。**今回は自社のキャラクターに声を当てて試しましたが、テキストのチャットボットとは明らかに別種の体験になります。 問い合わせ対応のような実務用途では会話精度が厳しく問われますが、**「会話すること自体が体験になる」用途であれば、現時点の精度でも成立する場面がありそうです。** ## よくある質問 ### 本当に20分で作れますか？ 基本形についてはそのとおりです。**約20分で音声エージェントの基本形を構築できました。**ただしこれは「動くものができる」までの時間であり、会話品質のチューニングやコスト設計は含みません。 ### 会話の精度は実用レベルですか？ **今回使用したGemini 2.0 Flashでは、正しい会話の成立に難がありました。**モデルを変えれば結果は変わる可能性が高いため、実用化を検討する際はモデル比較から始めることをおすすめします。 ### 費用はどのくらいかかりますか？ **この検証ではコスト試算を実施していないため、具体的な金額はお答えできません。**トークン消費と接続時間の両方が費用に効く構造のため、想定アクセス数を置いて試算する必要があります。 ### 問い合わせ対応に使えますか？ 会話精度の作り込み次第です。**音声会話は破綻が目立つため、テキストチャットボットより高い精度が求められます。**まずはモデル選定とコスト試算を済ませてから判断されることをおすすめします。 ## まとめ - ElevenLabs Conversational AIで、**約20分で音声エージェントの基本形を構築**。HP埋め込みまで確認 - 技術的なハードルは低く、試すだけならすぐ始められる - **会話精度はモデル選定に強く依存**。Gemini 2.0 Flashでは正しい会話の成立に難があった - **コストはトークン消費と接続時間の両方に効く**。実用化前の試算が必須 - 問い合わせ対応より先に、**会話自体が体験になる用途**のほうが現時点では噛み合いそう 作れることと運用できることの間には距離があります。音声AIは特に、コスト構造が従来のチャットボットと違う点に注意が必要です。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Kombaiでデザインをコードに変換する｜v0を上回る再現度と、実プロジェクトで残る手作業 - URL: https://ai-katsu.jp/articles/kombai-design-to-code - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-02T00:00:00+00:00 - Tools: Kombai, Figma - Tasks: 資料作成・デザイン, ツール検証 > Figmaデザインをコードに変換するKombai（VSCode/Cursor拡張）を検証しました。デザイン再現度はv0を上回った一方、実プロジェクトへの書き出しではNext.jsやTailwindの設定ファイルが不足し手動調整が必須に。「デザインの骨組みを高速生成するツール」として割り切る現時点の使い方をまとめています。 Figmaのデザインをそのままコードに変換できれば、フロントエンド開発の工数は大きく変わります。この領域のツールとして注目したのが Kombai です。VSCodeやCursorの拡張機能として動き、Figmaのデザインを読み込んでコードを出力します。 検証の結果、**デザインの再現度は高く、比較したv0を上回りました。**ただしそのまま動くコードが出てくるわけではありません。どこまでが「そのまま使える」のか、線引きを共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月（8/2〜8/8） | | 使用ツール | Kombai（VSCode / Cursor拡張機能）／ Figma | | やりたかったこと | Figmaデザインからプロダクトコードへの変換速度を最大化し、フロントエンド開発の工数を削減する | | 結論 | **デザイン再現度はv0より高い。**ただし実プロジェクトへの書き出しでは設定ファイルの不足があり、手動調整が必須 | | 判定 | 保留（実用化に向けた環境整備が必要） | | 現時点の使い方 | 「デザインの骨組み」を高速生成するツールと割り切る。細部のロジックはエンジニアが担当 | > 本記事は自社での検証記録です。工数削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：デザイン再現度は高い。ただし「プロダクトコード」ではない この検証で最も重要な発見がこれです。 **Figma全体のデザイン再現度に関しては、Kombaiのほうがv0より高いと評価しました。**見た目をどれだけ忠実に再現できるかという軸では、明確に強いツールです。 一方で、**出力されたコードがそのままプロダクトとして成立するわけではありません。**サンドボックス環境では優秀に動きますが、実際のプロジェクトに書き出すと話が変わります。 ## つまずいたこと：実プロジェクトへの書き出し 具体的に発生したのは、**Next.jsやTailwindの設定ファイルが不足するケース**です。生成されたコードは、それ単体では動く前提で書かれていますが、既存プロジェクトの構成と噛み合わないことがあります。 結果として、**出力されたコードを即座に動作させるための準備コストが発生しました。**設定ファイルを補い、既存の構成に合わせて整える工程が必要になります。 つまり、**デザインの忠実度と、開発環境との整合性は別問題**ということです。前者は解決されつつありますが、後者は人間が引き取る必要があります。 ## 現時点での使い方：骨組み生成として割り切る この制約を踏まえて、次のような切り分けを推奨しています。 | 工程 | 担当 | | --- | --- | | Figmaデザインの読み込み | Kombai | | デザインの骨組みとなるコード生成 | Kombai | | 設定ファイルの調整・既存構成への統合 | エンジニア | | 細部のロジック実装 | エンジニア | **「コードを書かなくてよくなるツール」ではなく「デザインからコードへの最初の一歩を飛ばすツール」と捉えると、期待値が合います。**ゼロからマークアップを起こす工程が省けるだけでも、効果は十分あります。 ## v0との比較 同じ領域のツールであるv0と比べると、性格の違いがはっきりしました。 | 観点 | Kombai | v0 | | --- | --- | --- | | Figmaデザインの再現度 | **より高い** | — | | 起点 | 既存のFigmaデザイン | プロンプトからの生成 | | 動作環境 | VSCode / Cursor拡張 | — | **すでにFigmaでデザインが固まっているならKombai、まだ形が決まっていないならv0**、という使い分けになりそうです。今回は「既存デザインの再現」という軸での比較であり、用途が違えば結論も変わります。 ## よくある質問 ### コードがそのまま使えないなら意味がないのでは？ マークアップをゼロから起こす工程が省けます。**デザインの構造をコードに落とす作業は手間がかかるため、そこが自動化されるだけでも効果はあります。**ただし「エンジニア不要になる」という期待には応えられません。 ### どのくらい工数が削減できますか？ **この検証では定量測定を行っていないため、削減率はお答えできません。**デザイン再現度が高いこと、および実プロジェクト適用には準備コストが発生することを確認した、という定性的な記録です。 ### なぜ「保留」なのですか？ 実用化に向けた環境整備が必要なためです。**設定ファイルの不足を毎回手作業で埋めていては、削減した工数が相殺されます。**プロジェクト側のテンプレートを整えるなど、受け入れ体制を作ってから本格導入する判断です。 ## まとめ - Kombaiの**Figmaデザイン再現度は高く、v0を上回った** - ただし**そのままプロダクトコードとして成立するわけではない**。Next.js/Tailwindの設定ファイル不足などで手動調整が必須 - デザインの忠実度と、**開発環境との整合性は別問題** - 現時点は**「デザインの骨組みを高速生成するツール」として割り切る**のが実用的。細部はエンジニアが担当 デザイン→コード変換ツールの評価では、生成物の見た目だけでなく「自分たちのプロジェクトに載るか」まで見る必要があります。サンドボックスでの印象と実プロジェクトでの手触りは、かなり違いました。 株式会社AI棒では、こうしたAIツールの検証を日々行い、企業の開発業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## n8nのフロー構築をAIに任せる｜MCPサーバー連携でドキュメント読み込み時間を削減した検証 - URL: https://ai-katsu.jp/articles/n8n-mcp-workflow - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-02T00:00:00+00:00 - Models: Claude - Tools: n8n, MCP - Tasks: 業務自動化・ワークフロー, ツール検証 > n8n MCPサーバーをClaude Desktopに接続し、チャット上で自然言語からワークフローを組み立てられるかを検証しました。AIが広範なノードを理解した上で提案するため、ドキュメント参照の時間が大幅に削減。一方でセットアップとAPI連携が煩雑で「上級エンジニア向け推奨」という判定に至った経緯をまとめています。 n8nは強力な自動化ツールですが、フローを組むにはノード（ブロック）の仕様を知っている必要があります。やりたいことが複雑になるほど、ドキュメントを読む時間が増えていきます。 この検証では、**n8n MCPサーバーをClaude Desktopに繋ぎ、チャット上で自然言語からワークフローを組み立てられるかを試しました。**結果として構築を大幅に支援できる手応えを得ましたが、セットアップの煩雑さから「上級エンジニア向け」という判定になっています。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月（8/2〜8/8） | | 使用ツール | n8n MCP server / Claude Desktop | | やりたかったこと | n8nでの複雑なフロー構築をAIで支援し、構築工数を削減する | | 結論 | チャット上でのフロー構築の基盤を確立。**構築を大幅にサポートできる可能性を確認** | | 判定 | 完了（**上級エンジニア向け推奨**） | | つまずいた点 | セットアップおよびAPI連携が煩雑 | > 本記事は自社での検証記録です。構築時間の短縮率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：AIがノードを理解しているので、ドキュメントを読む時間が消える この検証で最も効果を感じたのがここです。 **n8nの広範なノードをAIが理解した上でフローを提案してくれるため、ドキュメントを読み込む時間が大幅に削減されます。** n8nには非常に多くのノードがあり、「やりたいことに対してどのノードを使うのが正解か」を調べる工程が、実は構築時間の相当部分を占めます。AIがその部分を引き受けることで、**各ブロックの詳細な知識がなくても、自然言語で自動化フローを組み始められる**状態に近づきました。 ## やったこと ``` Claude Desktop ↓ n8n MCP server n8n のワークフロー作成・操作 ``` n8n MCPサーバーを導入し、Claude Desktopからn8nのワークフローを作成・操作できる構成を作りました。チャット上でフローを組み立てる基盤ができた形です。 ### MCPとは **MCP（Model Context Protocol）は、AIと外部ツールを接続するための標準規格です。**対応するMCPサーバーをAIクライアントに登録すると、AIがそのツールを直接操作できるようになります。今回はn8n用のMCPサーバーを使い、AIにn8nを触らせています。 ## つまずいたこと：セットアップの煩雑さ 「上級エンジニア向け推奨」という判定になった理由がこれです。 **セットアップおよびAPI連携が煩雑でした。**公式ガイドや技術ブログを参照しながら環境を構築する必要があり、手順どおりに進めれば終わる、という類の作業ではありません。 ここに、この構成の矛盾があります。**「ノードの知識がなくてもフローが組める」ことを目指した仕組みなのに、その環境を用意する段階でエンジニアの知識が要る**という構造です。 裏を返せば、**誰かがセットアップを済ませてしまえば、その先は知識がなくても使えます。**導入時にエンジニアが伴走する前提で計画するのが現実的です。 ## どんなチームに向くか - **すでにn8nを使っていて、フローが複雑化してきたチーム** — ドキュメント参照の時間削減が効く - **環境構築を担当できるエンジニアがいるチーム** — 最初の壁を越えられる - **自動化のアイデアは出るが、実装で止まりがちなチーム** — 自然言語からの着手が効く 逆に、**環境構築を任せられる人がいない状態で導入するのは避けたほうがよい**というのが今回の判定です。 ## よくある質問 ### n8nの知識がなくても使えますか？ **フローを組む段階では、知識がなくても始められます。**AIがノードを理解した上で提案してくれるためです。ただし環境のセットアップには相応の知識が必要なので、そこは分けて考えてください。 ### どのくらい構築工数が減りますか？ **この検証では定量測定を行っていないため、数値はお答えできません。**「ドキュメント読み込み時間の削減」という定性的な効果を確認した段階です。 ### セットアップはどのくらい大変ですか？ 公式ガイドや技術ブログを参照しながら進める必要がありました。**API連携の設定を含め、慣れていないと詰まりやすい部分です。**「上級エンジニア向け推奨」としているのは、この初期構築のハードルによるものです。 ## まとめ - n8n MCPサーバーとClaude Desktopで、**チャット上でのフロー構築の基盤を確立** - 最大の効果は**ドキュメント読み込み時間の削減**。AIが広範なノードを理解した上で提案してくれる - 各ブロックの詳細を知らなくても、**自然言語で自動化フローを組み始められる** - ただし**セットアップとAPI連携が煩雑**で、上級エンジニア向けという判定 - 導入時にエンジニアが伴走できる体制があるかが、実用化の分かれ目 AIによる支援ツールは「使い始めてからは楽だが、使い始めるまでが大変」という形をとることが多くあります。導入計画では、その最初の壁を誰が越えるのかを先に決めておくと躓きません。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## Microsoft ClarityをMCPで繋ぐ｜ページURLを渡すだけでユーザーの詰まりを要約させる - URL: https://ai-katsu.jp/articles/microsoft-clarity-mcp - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-08-02T00:00:00+00:00 - Models: Claude - Tools: Microsoft Clarity, MCP - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: マーケティング > Clarity MCPサーバーをClaude Desktopに接続し、ダッシュボードを開かずにサイト訪問者の挙動データを取得できるようにしました。ページURLを指定するだけでデッドクリックなどの行動を要約でき、GA4 MCPと同等の利便性を確認。一方でGoogle広告との連携情報は取得できないという制約も引き継いでいます。 Microsoft Clarityはヒートマップやセッション記録を無料で使える解析ツールですが、確認するにはダッシュボードにログインする必要があります。「このページ、どこでユーザーが詰まってる？」を知りたいだけのときに、その一手間が挟まります。 先に検証したGA4 MCPと同じ発想で、**Clarity MCPサーバーを構築し、チャットからサイト訪問者の挙動データを取得できるようにしました。**GA4と同等の利便性が確認できた一方、同じ制約も引き継いでいます。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年8月（8/2〜8/8） | | 使用ツール | Clarity MCP server / Claude Desktop | | やりたかったこと | 自社サイトのエンゲージメント情報を、ダッシュボードにアクセスせずMCP経由で取得する | | 結論 | チャット経由でのエンゲージメント情報取得に成功。**GA4 MCPと同等の利便性を確認し、実用化推奨** | | できなかったこと | GA4と同様、Google広告との直接連携情報は取得できない | > 本記事は自社での検証記録です。ログイン工数の削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：ページURLを渡すだけで、ユーザーの詰まりが要約される この検証で最も実用的だったのがこれです。 **特定のページURLを指定するだけで、そのページのユーザー行動を要約してくれます。**デッドクリック（反応しない箇所へのクリック）のような、改善のヒントになる挙動が言葉で返ってきます。 ヒートマップは視覚的で分かりやすい反面、「で、結局どこが問題なのか」を読み取るには慣れが要ります。**そこをAIが言語化してくれるため、解析ツールに不慣れなメンバーでも改善の議論に入れます。** ## 構成 ``` Claude Desktop ↓ Clarity MCP server（Microsoft公式） Microsoft Clarity のデータ → 訪問者の挙動・ヒートマップ・セッション情報 ``` 技術的なポイントとして、**Microsoft公式のMCPサーバーを使うことで安定したデータ連携が可能でした。**非公式の実装を挟まずに済むぶん、保守の面でも安心して使えます。 ## GA4 MCPとの関係 この検証は、先に実施したGA4 MCPの検証と同じ操作感を目指したものです。**結果として、GA4 MCPと同等の利便性が確認できました。** | ツール | 分かること | | --- | --- | | GA4 MCP | PV・セッション・流入元などの「数」 | | Clarity MCP | デッドクリックなどページ内の「挙動」 | **両方を繋いでおくと、「数字が落ちている」から「そのページのどこで詰まっているか」まで、チャットの中で追えるようになります。**数と挙動は別のツールに分かれているものですが、入口をAIに寄せると境目が消えます。 ## 制約：広告経由の流入分析には届かない GA4 MCPと同じ壁がここでも出ました。**Google広告との直接連携情報は取得できません。** 広告経由の流入がどう振る舞ったかを分析したい場合、この構成では完結しません。**広告分析については、別途Google Ads用のソリューションが必要になる**というのが今回の整理です。 解析ツール側のMCPを揃えても、広告データだけは別系統として残る。ここは構成を考える際の前提にしておく必要があります。 ## よくある質問 ### Clarityの画面を開かなくてよくなるということですか？ 日常的な確認については、そのとおりです。**ページURLを渡して挙動を要約させる、という使い方であればチャット内で完結します。**ヒートマップを実際に目で見て確認したい場面では、ダッシュボードを開くことになります。 ### GA4 MCPとどちらを先に入れるべきですか？ 見たいものによります。**アクセス数の推移を追いたいならGA4、ページ内での詰まりを見たいならClarityです。**両方入れておくと、数字から挙動まで一続きで追えるようになります。 ### 広告データはどうすればいいですか？ **この構成では取得できません。**Google Ads用の別のソリューションを併用する必要があります。GA4 MCPでも同じ制約があったため、解析ツール側のMCPだけでは広告分析は完結しない、と考えておくのが安全です。 ## まとめ - Clarity MCPにより、**チャット経由でサイト訪問者の挙動データを取得**できるようになった - **ページURLを指定するだけで、デッドクリックなどのユーザー行動を要約**してくれる - Microsoft公式のMCPサーバーを使うことで、安定したデータ連携が可能 - GA4 MCPと同等の利便性を確認。ただし**Google広告との連携情報は取得できない**という制約も同じ 解析ツールは入れたきり見なくなりがちですが、確認までの手数を減らすと参照される回数が変わります。今回はその手数を削る検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のデータ活用とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 予約・売上の自動取得を規約違反で断念した話｜技術的な「可能」とビジネス上の「許可」は別物 - URL: https://ai-katsu.jp/articles/reservation-sales-scraping - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-07-26T00:00:00+00:00 - Models: Claude - Tools: MCP - Tasks: リサーチ・データ収集, ツール検証 - Domain: 営業 > 予約管理画面から予約・売上情報を自動取得できないか、Claude DesktopとPlaywright MCPで検証しました。技術的には動的サイトの操作が可能だと確認できた一方、対象プラットフォームの約款にスクレイピング禁止条項があり実用化を断念。公式APIの確認を優先し、無ければ半自動化に留めるという方針転換に至った判断過程を公開します。 予約管理画面から予約状況や売上を毎日手で拾って集計する——現場からの「これを自動化したい」という声は非常に強いものでした。技術的には十分に実現可能です。実際、動的サイトを操作して情報を取得するところまでは動きました。 それでも、**この検証は実用化せずに中断しました。**理由は技術ではなく、利用規約です。判断に至った過程を記録として残します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年7月〜8月（7/26〜8/1） | | 使用ツール | Claude Desktop / Playwright MCP | | やりたかったこと | 予約管理プラットフォームの管理画面から、予約・売上情報を自動取得して集計する | | 技術的な結果 | Playwright MCPにより動的サイトの操作が可能であることを確認 | | 結論 | **利用規約のスクレイピング禁止条項に抵触するため中断。**積極的な推奨は避けるべきと判断 | | 代替方針 | 公式APIの有無を再確認する。無い場合はブラウザ操作を支援する「半自動化」に留める | > 本記事は自社での検証記録です。実運用は行っていないため、工数削減などの数値はありません。技術的な実装手順も、規約上の理由から掲載していません。 ## 結論：技術的な「可能」と、ビジネス上の「許可」は別物 この検証で最も大きな学びがこれです。 **AIとブラウザ自動化ツールを組み合わせれば、ログインが必要な動的サイトからでも情報は取得できます。**技術的なハードルは、以前と比べて大きく下がりました。「できるかどうか」で判断するなら、答えは「できる」です。 しかし実務では、その手前に確認すべきことがあります。**そのサイトの利用規約が、機械的な情報取得を許可しているかどうかです。** 今回対象としたプラットフォームの約款には、スクレイピングを禁止する条項（第14条10項）が置かれていました。この時点で、技術的な検証結果がどうであれ、実用化の選択肢は消えます。 ## なぜ「グレーゾーンだから様子見」にしなかったか 規約違反のリスクを承知の上で運用する、という判断もあり得ます。今回それを採らなかったのは、**大手プラットフォームの規約は厳格に運用されており、抵触した場合の社会的リスクが高い**と評価したためです。 利用規約と、過去の法的措置の事例をあわせて調査した結果、**積極的な推奨は避けるべき**という結論に至りました。アカウント停止にとどまらず、事業上の信用に関わる可能性を考えると、削減できる工数と釣り合いません。 > 自動化の検討では「できるか」を先に確かめたくなりますが、**規約の確認を先に置いたほうが、結果的に無駄が減ります。**今回は技術検証を進めた後に規約を精査したため、動くところまで作ってから止める形になりました。 ## 技術的に確認できたこと 実用化はしませんでしたが、技術検証としての収穫はありました。 **Playwright MCPを使うことで、動的サイトの操作がAI経由で可能であることを確認しました。**JavaScriptで描画されるページや、ログインが必要な画面でも、ブラウザを実際に動かす方式であれば扱えます。 この技術自体は、規約上問題のない対象——たとえば自社が管理するシステムや、自動取得が許可されているサイト——に対してであれば、有効な選択肢になります。**技術に問題があるわけではなく、適用先を選ぶ必要があるということです。** ## では、どうするか 現場のニーズ自体は消えません。中断後の方針として、次の順で検討することにしました。 1. **公式APIの有無を再確認する** — 提供されていれば、規約上も安全で保守性も高い。まずここを潰す 2. **「半自動化」に留める** — 全自動を諦め、人がブラウザを操作する作業を支援する範囲に絞る。ログイン後の画面遷移を補助する、取得したデータの整形だけを自動化する、といった形 **全自動でなくても、工数は下がります。**「規約に触れない範囲でどこまで楽にできるか」に発想を切り替えるほうが、結果的に長く使える仕組みになります。 ## よくある質問 ### スクレイピングは違法なのですか？ スクレイピングという行為が一律に違法というわけではありません。**問題になるのは、対象サイトの利用規約で禁止されている場合や、取得方法・利用目的が法令に触れる場合です。**今回は対象プラットフォームの約款に明確な禁止条項があったため、実用化を断念しました。判断は対象ごとに変わります。 ### 技術的な実装方法を知りたいのですが **本記事では実装手順を掲載していません。**規約で禁止されている対象への適用を助長しかねないためです。規約上問題のない対象に対してブラウザ自動化を検討されている場合は、個別にご相談ください。 ### 公式APIが無い場合はどうすればいいですか？ 全自動を諦め、**人の操作を支援する「半自動化」に留めるのが現実的です。**データの整形や集計だけを自動化するだけでも、日々の工数は下がります。規約に触れない範囲を先に確認してから、自動化の範囲を決めてください。 ## まとめ - Playwright MCPにより**動的サイトの操作は技術的に可能**だと確認できた - しかし対象プラットフォームの約款にスクレイピング禁止条項があり、**実用化を断念** - **技術的な「可能」とビジネス上の「許可」は別物。**大手の規約は厳格で、抵触時の社会的リスクが高い - 代替として、公式APIの確認を優先し、無ければ「半自動化」に留める方針とした - 自動化の検討では、**技術検証より先に規約の確認を置いたほうが無駄が少ない** AI活用の相談では「技術的にできるか」が話題になりがちですが、実務で効いてくるのは「やっていいか」の確認です。今回はそれを痛感した検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。規約やリスクを踏まえた実現可能性のご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## GA4の分析をチャットで完結させる｜Google Analytics MCPで日次レポートを自動生成した検証 - URL: https://ai-katsu.jp/articles/google-analytics-mcp - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-07-26T00:00:00+00:00 - Models: Claude - Tools: Google Analytics 4, MCP - Tasks: 開発・エンジニアリング, 業務プロジェクト - Domain: マーケティング > Google Analytics MCPをClaude Desktopに接続し、GA4のデータをチャットから直接取得できる環境を構築しました。複雑なUI操作を介さず自然言語でデータに届く快適さは高く評価された一方、Google広告の連携データは取得できないという制約も判明。取得できる範囲と、実用化に向けた線引きをまとめています。 GA4は多機能ですが、そのぶん画面が複雑です。「先週と比べてどうだったか」を知りたいだけなのに、ログインして、期間を設定して、レポートを選んで……という操作が毎回発生します。日次で見るとなると、この手間は無視できません。 そこで、**Google Analytics MCPを導入し、チャットに質問するだけでGA4のデータを取得できる環境を作りました。**結果は非常に実用的で、社内からも「すぐに使いたい」という反応がありました。取得できない領域もあったので、その線引きとあわせて共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年7月〜8月（7/26〜8/1） | | 使用ツール | Google Analytics MCP / Claude Desktop | | やりたかったこと | 日次のGA分析を効率化し、専門知識がなくても状況把握できるようにする | | 結論 | チャットUIから日次・週次レポートの自動生成に成功。**実用化推奨** | | できなかったこと | Google広告の連携データなど、GA4の標準指標の外にあるデータは取得できない | | 社内の反応 | 「すぐに使いたい」という評価 | > 本記事は自社での検証記録です。分析時間の短縮率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：GA4のUIを開かずに、自然言語でデータに届く この検証で得られた最大の価値は、**GA4の複雑なUI操作を介さずにデータへアクセスできることの快適さ**でした。 「先週のPVを教えて」「流入元の内訳を出して」といった質問をチャットに投げるだけで、答えが返ってきます。**GA4の画面構成を覚えていなくても、知りたいことを言葉にできれば届く**という状態です。 日次・週次のレポート生成も自動化できました。定型的な報告のために毎回ログインする、という作業がなくなります。 ## 構築の流れ ``` 1. Google Cloud 側で API キーを発行 2. Google Analytics MCP をインストール 3. Claude Desktop に MCP サーバーとして登録 4. プロンプトを投げて出力内容を検証 ``` 構成はシンプルで、**Claude DesktopからAPI経由で直接GA4のデータを取得します。**間に自作のサーバーやスクリプトを挟む必要はありません。 ### MCPとは **MCP（Model Context Protocol）は、AIと外部ツールを接続するための標準規格です。**対応するMCPサーバーを用意してAIクライアントに登録すれば、AIがそのツールを直接扱えるようになります。今回のGoogle Analytics MCPは、GA4のAPIをAIから使えるようにするものです。 ## 取得できたもの / できなかったもの | データ | 取得可否 | | --- | --- | | PV・セッションなどGA4の標準指標 | 網羅されている | | 流入元・ページ別などの基本的な内訳 | 取得できる | | **Google広告の連携データ** | **取得できない** | **GA4の標準的な指標は網羅されている一方、広告連携データなど一部は取得できませんでした。**マーケティングの分析では広告データを併せて見たい場面が多いので、ここは制約になります。 ### この制約への対応 現時点では、**GA4で取得可能な範囲に絞って運用する**方針としました。広告データが必要な分析については、Google広告専用のMCPが登場するのを待つ形です。 MCPは対応ツールが増え続けている領域なので、**「いま取れないもの」は時間が解決する可能性があります。**取れる範囲で運用を始めておき、後から広げるという進め方が現実的です。 ## どんな場面で効くか - **日次・週次の定型レポート** — 毎回同じ操作をしていたものが、質問1つに置き換わる - **GA4に慣れていないメンバーの状況把握** — 画面の使い方を覚えなくても数字に届く - **「ちょっと確認したい」の即時対応** — ログインする手間がないので、思いついたときに聞ける **専門知識の有無に関係なくデータに触れられるようになる**点が、組織として効いてくるところです。 ## よくある質問 ### GA4の知識がなくても使えますか？ 使えます。**むしろ「GA4のUI操作を覚えなくてよくなる」ことが、この構成の主な価値です。**知りたいことを自然言語で聞けば返ってきます。ただし指標そのものの意味（セッションとPVの違いなど）は理解しておいたほうが、解釈を誤りません。 ### Google広告のデータも見られますか？ **取得できません。**GA4の標準指標は網羅されていますが、広告連携データは今回の検証では取れませんでした。広告データが必須の分析には向きません。 ### 導入は難しいですか？ APIキーの発行とMCPのインストールが必要になります。Google Cloud側の設定に慣れていない場合は、ここが最初のハードルになります。**一度設定してしまえば、あとはチャットに質問するだけです。** ### どのくらい時間が短縮できましたか？ **この検証では定量測定を行っていないため、数値はお答えできません。**社内メンバーから「すぐに使いたい」という評価を得た、という定性的な反応にとどまります。 ## まとめ - Google Analytics MCPにより、**チャットからGA4のデータを直接取得できる**環境を構築 - 日次・週次レポートの自動生成に成功。**実用化推奨**と判断 - 最大の価値は**GA4の複雑なUI操作を介さずに済む快適さ**。専門知識がなくてもデータに届く - ただし**Google広告の連携データは取得できない**。取れる範囲で運用し、対応MCPの登場を待つ方針 分析ツールは「使いこなせる人」が限られがちですが、入口を自然言語に変えるだけで触れる人が一気に増えます。今回はその手応えが得られた検証でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のデータ活用とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 生成AIでUIデザインはどこまで作れるか｜v0を検証して分かった限界と「共作」という最適解 - URL: https://ai-katsu.jp/articles/frontend-design-validation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-07-19T00:00:00+00:00 - Tools: Vercel - Tasks: 資料作成・デザイン, ツール検証 > v0（Vercel）などのUI生成AIで、非エンジニアでもプロ級のデザインが作れるかを検証しました。基本的なレイアウトは高速に生成できる一方、ブランド独自の質感やインタラクティブ要素には限界があり、「AIっぽいデザイン」からの脱却が課題に。丸投げでも自作でもない「共作」スタイルが現時点の最適解という結論に至った経緯をまとめています。 「生成AIでどこまでデザインが作れるのか」「非エンジニアでもプロ級のUIを組めるのか」。デザイナーの工数削減とプロトタイプの高速化を狙って、v0（Vercel）をはじめとするUI生成AIを検証しました。 結論は、**基本的なレイアウトは驚くほど速く作れる一方、ブランド独自の「質感」には届かない**というものです。そして現時点の最適解は、丸投げでも自作でもなく「共作」でした。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年7月（7/19〜7/25） | | 使用ツール | v0（Vercel）ほか | | やりたかったこと | 生成AIでどの程度のデザイン制作が可能か、非エンジニアでもプロ級のUIを構築できるかを見極める | | 期待した効果 | デザイナー工数の削減、プロトタイプ作成の高速化 | | 結論 | 基本レイアウトは高速生成できるが、ブランド独自の質感やリッチなUI表現には限界。**AIの出力を人間が微調整する「共作」が最適解** | | 判定 | 追加検証が必要（ツール選定は継続中） | > 本記事は自社での検証記録です。制作時間の短縮率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：丸投げは成立しない。共作なら成立する UI生成AIに期待されがちなのは「指示だけで完成品が出てくる」という使い方です。**この期待に対しては、現時点では応えられないというのが検証の答えでした。** ただし「使えない」という話ではありません。**AIが生成したコードをベースに、人間が微調整していく「共作」スタイルであれば十分に実用的です。**ゼロから組む工程が省けるぶん、確実に速くなります。 問題は、どこまでをAIに任せ、どこから人が引き取るかの線引きです。今回の検証では、その境界がかなりはっきり見えました。 ## AIが得意なところ / 苦手なところ ### 得意：基本的なレイアウトの高速生成 一般的な構成のページであれば、レイアウトは高速に出てきます。ヘッダー・カード一覧・フォームといった定型的な組み合わせは、指示から短時間で形になります。**プロトタイプを作って議論の土台にする用途では、すでに十分な速度です。** ### 苦手その1：ブランド独自の「質感」 ここが最大の壁でした。**ブランドごとの空気感やリッチなUI表現には限界があります。**「整ってはいるが、どこかで見たことがある」という状態から抜け出しにくいのです。 AI生成のデザインは画一的になりやすい傾向があります。この「AIっぽいデザイン」からの脱却が、今回うまくいかなかった点です。 ### 苦手その2：インタラクティブな要素 動きのあるパーツ、状態によって見た目が変わる要素などは、**依然として人間の調整が必要でした。**静的なレイアウトと動きのあるUIとでは、AIの得意度がはっきり分かれます。 ## v0の位置づけ 複数のツールを見た中で、**現時点では v0 がコード生成まで含めた実用性で一歩抜き出ています。** デザインの見た目だけを出力するのではなく、そのまま使えるコードとして出てくる点が効いています。「共作」を前提にするなら、人間が引き取る対象がコードであることは重要です。画像だけ渡されても、そこから実装を起こす工程が残ってしまいます。 > なお本検証は「ツール選定継続」として保留にしています。この領域は動きが速く、比較対象も入れ替わるため、時期を置いて再評価する前提です。 ## 実務でどう使うか 検証を踏まえた現時点の使い方は、次のような分担です。 | 工程 | 担当 | | --- | --- | | たたき台のレイアウト生成 | AI | | プロトタイプでの合意形成 | AI出力をそのまま使う | | ブランドに合わせた質感の調整 | 人間 | | インタラクションの実装・調整 | 人間 | **「AIに作らせる」ではなく「AIに下書きさせる」と捉えると、期待値のズレが起きにくくなります。** ## よくある質問 ### 非エンジニアでもプロ級のUIが作れますか？ **現時点では難しいというのが検証の結論です。**基本的なレイアウトまでは到達できますが、そこから先の質感やインタラクションの調整には専門的な判断が必要になります。プロトタイプを作って議論する用途であれば、非エンジニアでも十分に活用できます。 ### デザイナーの工数はどのくらい削減できますか？ **この検証では定量測定を行っていないため、削減率はお答えできません。**ゼロから組む工程が省けるぶん速くなる、という定性的な手応えにとどまります。 ### 「AIっぽいデザイン」を避けるには？ 今回の検証範囲では、**人間が引き取って調整する以外の解決策は見つかりませんでした。**生成時の指示を工夫する余地はありますが、それだけで独自の質感まで到達するのは難しいという評価です。 ## まとめ - 基本的なレイアウトは**高速に生成できる**。プロトタイプ用途では十分実用的 - **ブランド独自の質感とインタラクティブ要素には限界**があり、人間の調整が必要 - 「AIっぽいデザイン」からの脱却が最大の課題 - 現時点の最適解は**丸投げでも自作でもなく「共作」**。AIの出力をベースに人間が仕上げる - コード生成まで含めた実用性では v0 が一歩抜き出ている AIツールの評価では「できる／できない」の二択で考えると判断を誤ります。どの工程までなら任せられるかを見極めるほうが、実務では役に立ちます。 株式会社AI棒では、こうしたAIツールの検証を日々行い、企業の制作業務へのAI活用を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## 請求書発行をMCPで自動化する｜Discord×スプレッドシートで帳票作成まで完結させた検証 - URL: https://ai-katsu.jp/articles/invoice-mcp-automation - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-07-12T00:00:00+00:00 - Models: Claude - Tools: MCP, Discord, Google Workspace - Tasks: 業務自動化・ワークフロー, 業務プロジェクト - Domain: バックオフィス > 請求書作成で本当に手間なのは、チャットに散らばった情報を台帳に転記する往復です。Discord MCPとGoogle Sheets MCPをClaude Desktopで束ね、依頼の取得から請求書出力までを一気通貫で自動化しました。自作サーバーをやめてスプレッドシートのテンプレート方式に切り替えた判断と、非エンジニアには難しい初期セットアップの実際を公開します。 請求書の作成そのものは難しい作業ではありません。手間なのは、その前段にある「情報集め」です。依頼はチャットに散らばり、金額や条件は個別のやりとりの中にあり、それを台帳に転記してからようやくフォーマットに流し込む。この転記の往復が、毎月ぶんだけ積み上がります。 この検証では、**Discordに届いた依頼情報を起点に、Googleスプレッドシートの台帳へ転記し、そのまま請求書として出力するまでを、複数のMCPサーバーを組み合わせてAI上で完結させました。**実装の過程で一度設計を大きく変えており、そこが最大の学びだったので、結論とあわせて共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年7月（7/12〜7/25） | | 業務領域 | バックオフィス（経理・請求業務） | | 使用ツール | Claude Desktop / Discord MCP / Google Sheets MCP | | やりたかったこと | 請求情報の収集からPDF作成までをワンクリックで完結させ、ヒューマンエラーと工数を減らす | | 結論 | Discord → スプレッドシート → 請求書出力の一気通貫フローを構築。実用レベルの出力を確認 | | 設計変更 | 当初案の「自作サーバーでPDF発行」は保守性が低く断念。スプレッドシートのテンプレート方式へ転換 | | 残った課題 | GCPのAPI設定と認証情報の管理が、非エンジニアには難解 | > 本記事は自社での検証記録です。定量的な効果測定（削減工数・エラー率など）はこの期間では実施していないため、数値は掲載していません。 ## 結論：複数のMCPサーバーを繋ぐと、ツールを跨ぐ作業がAI上で完結する この検証で確認できたのは、**MCPサーバーを複数組み合わせることで、これまで人間が「アプリ間を行き来して」やっていた作業を、AIとの対話ひとつに畳めるということです。** 今回の構成では、チャットツール（Discord）と表計算ツール（Googleスプレッドシート）という別々のサービスにまたがる作業を、Claude Desktop上のやりとりだけで完結させています。人間側の操作は「請求書を作って」と指示するところだけです。 MCPを単体で試すと「便利なAPI連携」という印象で止まりがちですが、**複数を繋いだときに初めて、業務フローそのものを置き換える手応えが出ました。** ## MCPとは何か **MCP（Model Context Protocol）は、AIと外部ツールを接続するための標準規格です。**従来なら「ChatGPTにSlack連携機能を作る」「Claudeにスプレッドシート連携を作る」といった具合に、AIとツールの組み合わせごとに個別実装が必要でした。MCPはその接続部分を共通化します。 実務上の意味は、**ツールを足すたびにゼロから作らなくてよくなる**ということです。今回のようにDiscordとGoogleスプレッドシートを両方繋ぐ場合も、それぞれのMCPサーバーを用意してAIクライアントに登録するだけで済みます。 ## 構築したフロー ``` Discord（依頼元） ↓ Discord MCP で依頼情報を取得 Googleスプレッドシート（管理台帳） ↓ Google Sheets MCP で転記 請求書テンプレート（同じくスプレッドシート） ↓ テンプレートに流し込んで出力 請求書 ``` ポイントは、**台帳と請求書テンプレートの両方をスプレッドシート上に置いたこと**です。この判断に至った経緯は次のセクションで詳述します。 ### 使用したツール | ツール | 役割 | | --- | --- | | Claude Desktop | MCPサーバーを束ねるAIクライアント。ここで指示を出す | | Discord MCP | 依頼が投稿されるチャンネルから情報を取得する | | Google Sheets MCP | 管理台帳への転記と、請求書テンプレートへの流し込み | ## 最大の判断：自作サーバーをやめてスプレッドシートに寄せた **当初は「請求書PDFを発行する専用サーバーを自作する」構成を検討していました。これは途中で取りやめています。** 理由は保守性です。専用サーバーを立てると、請求書のフォーマットを少し変えたいときにも開発側の対応が必要になります。「消費税の表記を変えたい」「振込先を追加したい」といった、経理担当者にとっては当たり前の微修正のたびに、エンジニアを待つことになる。この構造が現場で回らないと判断しました。 代わりに採用したのが、**Googleスプレッドシートのテンプレート機能を読み込む方式**です。請求書のレイアウトはスプレッドシート上のテンプレートとして持ち、AIはそこにデータを流し込むだけの役割にしました。 これにより、**フォーマットの変更を現場で完結できる**ようになりました。経理担当者が普段どおりスプレッドシートを編集すれば、それがそのまま次回の請求書に反映されます。 > 自動化の設計では「どこまでをAIに任せ、どこを人が触れる状態に残すか」の線引きが効いてきます。今回は**見た目の定義を人の手元に残した**ことが、実用性を大きく上げました。 ## やってみて分かったこと ### うまくいったこと 複数のMCPサーバーを組み合わせ、**ツールを跨ぐ作業をAI上で完結させられました。**出力された請求書は実用レベルの品質で、他社に事例として提示できる完成度に達しています。 ### つまずいたこと：導入時のセットアップが非エンジニアには難解 **この構成の最大のハードルは、日々の運用ではなく初期セットアップにあります。**具体的には、GCP側のAPI設定と、認証情報（クレデンシャル）の管理です。 Google Sheets MCPを動かすには、GCPプロジェクトを作り、必要なAPIを有効化し、認証情報を発行して安全に保管する、という一連の作業が必要になります。ここは画面の指示に従うだけでは進みにくく、**非エンジニアが独力で越えるのは難しい**というのが率直な評価です。 裏を返せば、**一度セットアップさえ済めば、あとは現場だけで回せます。**導入時にエンジニアが伴走する前提で計画するのが現実的です。 ## この仕組みが応用できる範囲 今回作ったものは、抽象化すると**「特定プラットフォームに散らばった情報を、帳票の形にまとめる仕組み」**です。請求書という出力先を差し替えれば、そのまま他の定型業務に応用できます。 - **総務** — 各所からの申請・依頼を集約して台帳化する - **人事** — 応募や問い合わせの情報を定型フォーマットにまとめる - **経理** — 請求以外の帳票（見積書・支払通知など）へ横展開する 情報の入口（今回はDiscord）も出口（今回は請求書テンプレート）も差し替え可能なので、**自社の業務でどのチャネルに情報が散らばっているかを起点に考えると、適用先が見つけやすくなります。** ## よくある質問 ### Discord以外のチャットツールでも同じことはできますか？ できます。今回はDiscord MCPを使いましたが、対応するMCPサーバーがあるツールであれば、同じ考え方で置き換えられます。MCPが接続部分を共通化しているため、入口のツールが変わっても全体の設計は変える必要がありません。 ### 非エンジニアだけで導入できますか？ **初期セットアップは難しいと考えてください。**GCPのAPI設定と認証情報の管理という、慣れていないと詰まりやすい工程があります。ただし運用フェーズはスプレッドシートの操作が中心になるため、導入さえ越えれば現場だけで回せます。 ### 請求書のフォーマットを変えたくなったらどうしますか？ スプレッドシート上のテンプレートを直接編集してください。開発側の対応は不要です。これは今回、自作サーバー方式をやめてテンプレート方式に切り替えた、まさにその狙いにあたる部分です。 ### どのくらい工数が削減できましたか？ **この検証期間では定量的な測定を行っていないため、数値はお答えできません。**実運用を開始してエラー率を確認する段階を次のアクションとしています。 ## まとめ 請求書発行という定型業務を題材に、複数のMCPサーバーを繋いだ自動化を検証しました。 - **MCPは複数繋いで初めて業務フローを置き換える**。単体では便利なAPI連携の域を出ない - **自作サーバーではなくスプレッドシートのテンプレートに寄せた**。フォーマット変更を現場で完結させるための判断 - **最大のハードルは運用ではなく初期セットアップ**。GCPのAPI設定と認証情報管理は非エンジニアには難しい - 「情報を集めて帳票にする」構造は、総務・人事など他の定型業務にも応用できる 自動化の成否は、AIの性能よりも「どこを人が触れる状態に残すか」の設計で決まる場面が多くあります。今回はその一例として参考にしていただければと思います。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化とAI導入を支援しています。自社の業務でどこから手をつけるべきかのご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## ExcelでAI関数を自作する｜LM Studio×ローカルLLMを検証し全社展開を見送った理由 - URL: https://ai-katsu.jp/articles/excel-ai-poc - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-07-05T00:00:00+00:00 - Tools: Excel - Tasks: 開発・エンジニアリング, ツール検証 > Excelのセルから直接AIを呼び出す「AI関数」を、LM StudioのローカルLLMと繋いで自作しました。技術的には動作したものの、高スペックPCが必須で全社展開は非現実的と判断し不採用に。機密データを外に出さずに処理できるという利点と、実用化するならクラウドAPIに切り替えるべきという結論をまとめています。 Excelのセルに `=AI("この文章を要約して", A1)` のような関数を書いて、そのままAI処理ができたら便利です。しかも社外にデータを出さずに。この発想でローカルLLMとExcelを繋ぐ仕組みを作り、**技術的には動作したものの、全社展開は見送りました。** 見送りの理由は精度でも機能でもなく、PCスペックでした。同じ構成を検討している方に向けて、判断の経緯を共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年7月（7/5〜7/11） | | 使用ツール | Microsoft Excel + LM Studio（ローカルLLM） | | やりたかったこと | Excel内から直接AIを呼び出す「AI関数」を作り、データ整理などの日常業務を効率化する | | 結論 | 技術的な実現性は確認できたが、動作が重く高スペックPCが必須。**全社展開は非現実的と判断し不採用** | | 判定 | 導入見送り（検証終了） | | 得られた知見 | 実用化を目指すならクラウドAPI（Azure OpenAIなど）に切り替えるべき | > 本記事は自社での検証記録です。処理速度は「重い」という定性評価にとどまり、秒数などの定量測定は行っていないため数値は掲載していません。 ## 結論：動くが、配れない **仕組み自体は完成しました。**Excelシート上から自作のAI関数を呼び出し、セル内のデータに対してAI処理を実行できています。技術的な実現性という意味では、検証は成功と言えます。 それでも見送ったのは、**この構成が「配布できるもの」にならなかったからです。**ローカルLLMを動かすには相応のPCスペックが必要で、そこがボトルネックになりました。 全社員のPCにLM Studioを入れて回してもらう、という運用は現実的ではありません。**一部の人しか使えないツールは、業務改善の手段としては成立しにくい**という判断です。 ## 作ったもの ``` Excel（セルに数式を入力） ↓ マクロ LM Studio のローカルAPI ↓ ローカルLLMで処理 ↓ Excelのセルに結果を返す ``` ExcelマクロからAPI経由でLM Studioを呼び出す構成です。LM StudioはローカルPC上でLLMを動かすツールで、APIサーバーとしても起動できます。**この構成の要点は、データが一度もPCの外に出ないこと**です。 ## この構成の価値：機密データを外に出さずに処理できる 見送りはしましたが、**ローカルLLMを使う最大の利点は確認できました。** クラウドのAIサービスを使う場合、処理したいデータは必ず外部に送信されます。顧客情報や未公開の数値を含むExcelファイルでは、そこが導入の壁になることがあります。ローカルLLMならこの問題が発生しません。 **「セキュリティ要件が厳しくてクラウドAIを使えない」という制約下では、ローカルLLMは有力な選択肢になります。**今回の検証は、その可能性を確認できた点に意味がありました。 ## つまずいたこと：推奨スペックの壁 不採用の直接の理由はこれです。 **ローカルPCでLM Studioを起動するには、高いPCスペックが求められます。**動作は重く、一般的な業務用PCで快適に回せるものではありませんでした。導入時のLM Studioインストール自体もハードルが高い部類に入ります。 技術的に可能でも、**全社員に配れないなら業務改善のツールとしては成立しません。**「一部の高スペックPC保有者だけが使える効率化」は、組織全体で見ると効果が限定的です。 ## 実用化するなら：クラウドAPIに切り替える 同じ「ExcelからAI関数を呼ぶ」構成を本気で実用化するなら、**呼び出し先をローカルLLMからクラウドAPI（Azure OpenAIなど）に変えるべき**というのが今回の結論です。 | 項目 | LM Studio（ローカル） | Azure OpenAI（クラウド） | | --- | --- | --- | | データの保管場所 | ローカル。外部に出ない | クラウドへ送信される | | 環境構築 | 高スペックPCが必須 | 環境構築が不要 | | 全社展開 | 非現実的 | 現実的 | クラウドAPIならPCスペックに依存しないため、配布可能な仕組みになります。**データを外に出せるかどうかで、選ぶべき構成が変わる**という整理です。 ## 残した可能性 全社展開は見送りましたが、適用先を絞れば話は変わります。追加で確かめたいのは、**高スペックPCを持つエンジニア部門に限定した、ニッチな作業効率化**です。 この条件なら「スペックの壁」は最初から存在しません。機密データを扱う分析作業などでは、噛み合う場面がありそうです。 ## よくある質問 ### ExcelのAI関数は自作しないと使えませんか？ 今回はマクロからAPIを呼び出す方式で自作しました。Microsoft自身もExcelへのAI機能統合を進めているため、標準機能で足りるかを先に確認するほうが早い場合があります。**今回検証したのは、自前でローカルLLMに繋ぐ構成です。** ### どのくらい重かったですか？ **この検証では処理速度の定量測定を行っていないため、秒数などはお答えできません。**定性評価として「重い」「高スペックPCが必要」という判断に至った、というのが記録の全てです。 ### ローカルLLMは業務では使えないということですか？ そうではありません。**今回の「全社員のPCで動かす」という前提と噛み合わなかっただけです。**機密データを扱う特定部門に絞る、あるいはサーバー側で動かして社内から呼ぶ構成にするなど、前提を変えれば選択肢に残ります。 ## まとめ - Excel + ローカルLLMのAI関数は**技術的には動作した**が、全社展開は見送り - 理由は精度や機能ではなく**PCスペック**。動作が重く、配布可能な仕組みにならなかった - ローカルLLMの価値は**機密データを外に出さずに処理できる**点。ここは確認できた - 実用化を目指すなら**クラウドAPI（Azure OpenAIなど）に切り替える**のが現実的 社内ツールの検討では「動くかどうか」より「全員に配れるかどうか」で結論が決まる場面が少なくありません。今回はその典型例でした。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務効率化とAI導入を支援しています。自社の環境に合う構成のご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## マーケティングにコーディングCLIは必要か｜Claude Code・Gemini CLIを試して見送った理由 - URL: https://ai-katsu.jp/articles/coding-cli-marketing - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-07-05T00:00:00+00:00 - Models: Claude Code, Gemini - Tasks: 開発・エンジニアリング, ツール検証 - Domain: マーケティング > Claude CodeやGemini CLIにローカルのMarkdownを読ませ、マーケティング施策の立案を効率化できないか検証しました。結論は「一般的な用途ならチャットUIで十分」。非エンジニアにとってCLIのハードルを越えるだけの差分が見つからなかった一方、ローカル情報をRAG的に扱える手応えとMCP連携の拡張性は確認できました。判断の根拠を公開します。 Claude CodeやGemini CLIといったコーディング用のCLIツールは、ローカルのファイルを直接読み込んで処理できます。ならば手元のMarkdownに溜めた事業情報を読ませれば、経営分析やマーケティング施策の立案にも使えるのではないか——そう考えて検証しました。 結論から言うと、**一般的なマーケティング用途であれば、わざわざCLIを使う必要はありませんでした。**通常のチャットUIで十分です。ただし検証の過程で、CLIならではの手応えも確認できています。判断の根拠とあわせて共有します。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年7月（7/5〜7/11） | | 使用ツール | Claude Code / Gemini CLI | | やりたかったこと | ローカルのMarkdownファイルを読み込ませ、経営分析やマーケティング施策の立案を効率化する | | 結論 | 一般的なマーケティング用途なら通常のチャットUIで十分。CLIを選ぶ理由が見つからなかった | | 判定 | 条件付きで導入可（保留・手法の再検討） | | 費用 | Claude Code：従量課金／Gemini CLI：無料枠あり | > 本記事は自社での検証記録です。この検証では処理速度や工数削減率などの定量測定は行っていないため、数値は掲載していません。 ## 結論：CLIである必要性が説明できなかった 検証を進める中で最後まで答えが出なかったのが、**「なぜCLIである必要があるのか」**という問いでした。 CLIツールはターミナル操作が前提です。マーケティング担当者や経営企画の担当者にとって、これは相応のハードルになります。そこを越えてまで得られるものが、チャットUIとの比較で明確に説明できませんでした。 **一般的なマーケティング施策の立案であれば、推論モデルを備えた通常のチャットUIで十分な品質が得られます。**ファイルを添付すれば読み込みもできます。CLIの学習コストを組織に負わせるだけの差分が見つからない、というのが率直な評価です。 ## やったこと Claude CodeとGemini CLIの両方で、次のフローを実行しました。 ``` ローカルの .md ファイル（事業情報・分析メモ） ↓ CLI で読み込み マーケティング施策案の生成 ↓ 施策案.md として出力 ``` 入力も出力もローカルのMarkdownファイルで完結する構成です。 ### 2つのCLIの比較 | 項目 | Claude Code | Gemini CLI | チャットUI | | --- | --- | --- | --- | | 出力の粒度 | — | より細かな出力が得られた | — | | コスト | 従量課金 | 無料枠あり | — | | 使いやすさ | エンジニア向け | エンジニア向け | 非エンジニアも対応可 | | 連携性 | MCP連携が可能 | — | — | この用途に限れば、**Gemini CLIのほうが細かい出力が得られました。**無料枠がある点も、試すだけなら扱いやすいところです。 ## 収穫：ローカル情報をRAGのように使える手応え 見送りの判断とは別に、確認できた価値もあります。 **ローカルに置いたMarkdownを、RAG（外部知識参照）のように扱える手応えが得られました。**社内にしかない情報を、クラウドにアップロードせずAIに参照させられるということです。データがローカルに留まる点は、扱う情報によっては効いてきます。 加えて、コンテキストの保持やMCP連携といった拡張性の高さも確認できました。**CLIの本領はこちら側にあります。**単発の施策案を作らせるだけなら、その拡張性は活きません。 ## どういう場合なら使う価値があるか 今回の検証で見えたのは、**「CLIが向くのは、CLIでしかできないことをやるとき」**という当たり前の結論でした。具体的には次のような条件が揃う場合です。 - **操作する人がすでにターミナルに慣れている** — 学習コストが発生しない - **参照させたい情報がローカルにあり、外に出したくない** — クラウドへのアップロードを避けたい - **一度きりでなく、繰り返し実行する処理である** — 自動化やMCP連携の拡張余地が活きる 逆にこれらに当てはまらないなら、チャットUIを選んだほうが早いというのが今回の整理です。 ## 次に検証したいこと 本検証は「保留（手法の再検討）」として一旦止めています。あらためて確かめたいのは、**エンジニアが自社のコードベースを理解した上で、そこからマーケティング資料を生成するケース**です。 この場合は「操作者がCLIに慣れている」「参照対象がローカルにある」という条件が最初から満たされます。今回の用途とは前提が違うため、結論も変わる可能性があります。 ## よくある質問 ### Claude CodeとGemini CLI、どちらが良かったですか？ この用途に限れば**Gemini CLIのほうが細かな出力が得られました。**ただし比較したのはマーケティング施策の立案という単一の用途であり、本来の用途であるコーディング支援での比較ではありません。 ### CLIを使うとコストは下がりますか？ Gemini CLIには無料枠があるため、試す段階のコストは抑えられます。Claude Codeは従量課金です。ただし今回は**コスト削減を目的とした検証ではなく、削減額の測定も行っていません。** ### 非エンジニアでも使えますか？ 使えないことはありませんが、**おすすめしません。**ターミナル操作の習得コストに見合う効果が、一般的なマーケティング用途では見つかりませんでした。同じ目的ならチャットUIのほうが確実です。 ## まとめ - 一般的なマーケティング用途では、**CLIを使う理由が見つからなかった**。チャットUIで十分 - 非エンジニアにとってCLIのハードルは高く、それを越える差分を説明できなかった - 一方で**ローカル情報をRAG的に扱える手応え**と、MCP連携などの拡張性は確認できた - CLIが活きるのは、操作者が慣れていて・情報がローカルにあり・繰り返し実行する処理の場合 新しいツールを見ると「何に使えるか」を考えたくなりますが、既存の手段で足りるなら無理に置き換える必要はありません。今回はその線引きをした記録です。 株式会社AI棒では、こうしたAIツールの検証を日々行い、企業のAI活用を支援しています。自社に合うツール選定のご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## MCPで外部SNSにつなぐときの落とし穴｜接続は簡単、分けるべきはアカウント - URL: https://ai-katsu.jp/articles/meta-mcp - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-04-01T00:00:00+00:00 - Tools: MCP, Instagram - Tasks: 開発・エンジニアリング, ツール検証 > Meta系プラットフォームへのMCP接続を検証しました。接続自体は特殊な手順なく簡単に行える一方、APIキーは共用せず個別アカウントで発行する必要があります。技術的につながることと安全に運用し続けることは別、という運用設計の話をまとめています。 MCPで外部サービスにつなぐとき、技術的な接続手順よりも**アカウントとAPIキーをどう用意するか**のほうが実務上の判断を要することがあります。 この検証では、Meta系のプラットフォーム（Facebook / Instagram）へのMCP接続を試しました。**接続自体は簡単でしたが、運用面で1つ押さえるべき点が見つかっています。** ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年4月〜（保留中） | | 対象 | META MCP（Facebook / Instagram関連） | | 検証内容 | MCP接続の検証／APIキー発行の検証 | | 関連API | Facebook Graph API（Batch Requests）／Instagram Platform Webhooks | | 判定 | **条件付きで導入可**（現在は保留） | > 本記事は検証の初期段階の記録です。実運用での定量評価は未実施のため、数値は掲載していません。 ## 結論：接続は簡単、運用の設計に注意 この検証で確認できたことは2点です。 **① MCP接続に関しては、特殊な手順等なく簡単に接続可能でした。** **② APIキーは共用ではなく、個別アカウントを作成して発行する必要があると考えられます（BAN対策のため）。** 1つ目は良いニュースです。**MCPという規格が整備されていることで、接続部分の実装コストは下がっています。** 問題は2つ目です。**技術的につながることと、安全に運用し続けられることは別**という話になります。 ## なぜ共用APIキーが問題になるのか SNSプラットフォームのAPI利用では、共用のキーを複数用途で使い回すことにリスクがあります。 **1つの用途で規約に触れる動作をした場合、そのキーで動いている他の仕組みも巻き添えで停止する**可能性があるためです。 アカウント停止は、SNSを使った業務では事業の継続に直結します。**影響範囲を分離しておくことが、リスク管理になります。** この検証では、**共用ではなく個別アカウントを作成し、APIキーを発行する**という方針を立てています。 ## 接続先となるAPI | API | 特徴 | | --- | --- | | **Facebook Graph API（Batch Requests）** | 複数のリクエストをまとめて送れる | | **Instagram Platform Webhooks** | イベント発生時に通知を受け取れる | この2つは性質が違います。 **Batch Requestsは「こちらから取りに行く」仕組み**で、複数の問い合わせをまとめられるためリクエスト数を抑えられます。 **Webhooksは「向こうから通知が来る」仕組み**で、定期的なポーリングが不要になります。 **取得と通知を組み合わせると、無駄な問い合わせを減らせます。**常時ポーリングする設計は、レート制限にもコストにも不利です。 ## MCPで接続することの意味 APIを直接叩く実装と比べたときの違いです。 MCPサーバーとして接続できれば、**AIエージェントからツールとして呼び出せる**状態になります。個別にAPIクライアントを実装する必要がなくなります。 一方で、**認証情報の管理は依然として自分側の責任**です。接続が簡単になっても、キーの発行・保管・分離という設計は変わりません。 ## 導入前に決めておくこと この検証から導ける、事前に決めておくべき項目です。 - **用途ごとにアカウントとAPIキーを分けるか**（BAN時の影響範囲） - **取得はBatchで行うか、通知はWebhookで受けるか** - APIキーをどこに保管するか（コードに含めない） - 停止した場合の代替手段があるか **接続してから考えると、後から分離するのは手間になります。**最初に決めておくべき部分です。 ## よくある質問 ### MCP接続は難しいですか？ **この検証では、特殊な手順なく簡単に接続できました。**MCPという規格が整備されていることで、接続部分の実装コストは下がっています。 ### なぜ個別アカウントが必要なのですか？ **BAN対策のためです。**共用キーを使い回すと、1つの用途で問題が起きたときに他の仕組みも巻き添えで停止する可能性があります。 ### Batch RequestsとWebhooksの違いは？ **Batch Requestsは複数の問い合わせをまとめて送る仕組み、Webhooksはイベント発生時に通知を受け取る仕組みです。**組み合わせることで、無駄なポーリングを減らせます。 ## まとめ - **MCP接続は特殊な手順なく簡単に行えた** - ただし**APIキーは共用せず、個別アカウントで発行する**（BAN対策） - **技術的につながることと、安全に運用し続けられることは別** - 取得は**Batch Requests**、通知は**Webhooks**で組み合わせると無駄な問い合わせを減らせる - 用途ごとの分離は**接続前に決めておく**。後から分けるのは手間になる 外部サービスとの連携では、つなぐ手順より止まったときの影響範囲を先に設計しておくと安心して運用できます。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAI導入と外部連携の設計を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 --- ## クラス名を指定するだけでスライドが組める｜Marpで背景ごとの体裁を事前定義する - URL: https://ai-katsu.jp/articles/marp-cli-slide - Author: AI活編集部 (@ai-katsu-editorial) - Published: 2025-04-01T00:00:00+00:00 - Tools: Marp - Tasks: 資料作成・デザイン, ツール検証 > 企業向けスライドで背景ごとに文字サイズや位置を毎回調整する手間を、事前定義で解消する仕組みを作りました。Markdownベースのため大量作成・一括修正・AIによる生成に強く、PowerPoint出力後の微調整も可能です。「毎回同じ判断をしているなら定義に落とせる」という設計の考え方をまとめています。 企業向けのスライドは、背景がテンプレート化されていることが多くあります。しかしテンプレートがあっても、**背景ごとに文字のサイズや位置を毎回調整する**手間は残ります。 この検証では、Marp CLIで**背景ごとの文字サイズ・位置を事前定義し、クラス名の指定だけでシートを構築できる仕組み**を作りました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2025年4月〜（保留中） | | 対象 | Marp CLI（Markdownでスライドを作成し、PowerPoint等へ出力） | | 作ったもの | **背景ごとの文字サイズ・位置を事前定義し、クラス名指定でシートを構築できる仕組み** | | 判定 | **条件付きで導入可**（現在は保留） | > 本記事は検証段階の記録です。定量的な効果測定は実施していないため、数値は掲載していません。 ## 結論：クラス名だけで組めるようにする この仕組みの狙いはシンプルです。 **それぞれの背景に対して表示される文字のサイズや位置を事前定義することで、使う側はクラス名の指定だけで、使いたいシートを素早く構築できます。** テンプレートがあっても、通常はこうなります。 - この背景では文字が右に寄る → 位置を調整 - この背景は暗い → 文字色を変える - タイトル用の背景だから文字を大きく → サイズを調整 **調整の内容は背景ごとに決まっているのに、毎回手作業で行っている**状態です。ここを事前定義に落とせば、使う側は「どの背景を使うか」を指定するだけで済みます。 ## Markdownで作る意味 Marpの基本的な特性です。 - **Markdown形式でスライドを作成できる** - **PowerPoint等へ出力できる** この組み合わせが実務で効きます。 **PowerPointへ出力した後は編集も可能なので、微調整はそちらで行うという使い方ができます。** **「AIやスクリプトで一気に作り、最後の仕上げは手作業」という分担が成立します。**すべてをコードで完結させる必要はありません。 ## この設計が効く場面 テキストベースでスライドを作れることには、いくつかの副次的な利点があります。 | | GUIツール | Markdown + クラス指定 | | --- | --- | --- | | 1枚作る | 直感的 | 記法の習得が必要 | | **大量に作る** | 毎回同じ操作 | **テキストを書くだけ** | | **一括修正** | 1枚ずつ直す | **定義を直せば全体に反映** | | 差分の確認 | 難しい | **テキストなので差分が見える** | | AIに書かせる | 難しい | **そのまま生成できる** | **「AIに書かせる」という点が、この形式の現在的な価値です。**Markdownはテキストなので、生成させてそのまま流し込めます。 クラス名で見た目が決まる設計なら、**AIには内容とクラス名だけを出力させればよく、レイアウト調整を任せる必要がありません。** ## 事前定義という考え方 この検証の本質は、Marpという特定ツールの話ではありません。 **「毎回同じ判断をしているなら、それは定義に落とせる」**という設計の考え方です。 背景ごとの文字サイズと位置は、本来は決まっているものです。それを毎回手で調整しているのは、**判断が仕組みに落ちていないだけ**です。 一度定義してしまえば、以降は選ぶだけになります。**作業が判断から選択に変わります。** ## よくある質問 ### Marpとは何ですか？ **Markdown形式でスライドを作成できるツールです。**PowerPoint等への出力にも対応しています。 ### PowerPointで編集できますか？ **できます。**出力後の編集が可能なため、微調整はPowerPoint側で行うという使い方ができます。 ### この仕組みの利点は？ **背景ごとの文字サイズ・位置を事前定義することで、使う側はクラス名を指定するだけでシートを構築できます。**毎回の調整作業が不要になります。 ### どんな場面に向いていますか？ **テンプレートが決まっていて、同じ形式のスライドを繰り返し作る場面です。**1枚だけ作るならGUIツールのほうが直感的です。 ## まとめ - 背景ごとの**文字サイズ・位置を事前定義**し、クラス名指定でシートを構築できる仕組みを作成 - Markdownで作成し**PowerPointへ出力。微調整は出力後に行える** - テキストベースの利点は**大量作成・一括修正・差分確認・AIによる生成** - クラス名で見た目が決まる設計なら、**AIには内容とクラス名だけを出力させればよい** - 本質は**「毎回同じ判断をしているなら、定義に落とせる」**という考え方 資料作成の効率化は、作る速度を上げることより、判断の回数を減らすことで進みます。決まっているものを定義に落とせば、以降は選ぶだけになります。 株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の資料作成業務へのAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。 ---