Showing Posts From
Ai活用
ブログ別ペルソナでAIドラフトを安定化する方法
同じAIに書かせているはずなのに、ブログによって文体が微妙に混ざる。 複数ブログを運営していると、これがじわじわ効いてくる。E-E-A-Tの軸が記事ごとにぶれるし、毎回フロントマターを手作業で整えるのも地味に重い。 あなたはどうだろう。AIに書かせる時、毎回プロンプトを書き直している派？ それとも仕組みで固定してしまう派？ 私は後者に寄せた。プロンプトを毎回工夫するより、ブログごとに執筆者ペルソナを固定する方が、結果的に早いし安定するとわかったからだ。 いま起きている課題ブログごとの語り口が混ざる E-E-A-Tの軸が記事ごとにぶれる 毎回フロントマターを手作業で整えるのが重い解決の軸は2つだけブログごとに執筆者ペルソナを固定する ドラフト昇格時にvoiceを自動で入れるこの2つを守るだけで、AIの出力はかなり安定するわけだ。 ブログ別ペルソナ（要点） 私が運営している各ブログには、それぞれ固有のペルソナを設定している。 釣！浜名湖釣り歴20年以上、浜名湖ローカルに強い実践型 実験・検証を重視した語り口 地域特性とポイント解像度で信頼性を担保する海上アングラー海上釣り堀の普及を目的にしたナレッジ提供型 テクニックだけでなく旅行導線も提案する 「釣る技術＋行き方」の二軸で価値を作る防音Lab防音の専門家ではなく、生活者目線のアドバイザー型 課題に対して複数案を出し、比較して最適解を探る ニッチ需要まで拾う設計で差別化するシラバスハック資格学習と生成AIの掛け合わせに強い実践型 高額教材依存を減らし、効率学習を支援する 非エンジニアにも伝わる再現性を重視する実装ルール（最小構成） voiceはドラフト化のタイミングだけ付与する。_inbox段階では空でもよく、_draftへ昇格するときにだけ設定する。 voice: id: cho-hamanako label: 釣！浜名湖フラット運用にするなら以下でも可だ。 voice: cho-hamanako運用フロー（短縮版）メモを整理して主要タグを付与する タグまたは保存先からvoice.idを判定する ドラフト生成時にペルソナ文脈を挿入する 最後にE-E-A-T観点で1回だけ手修正するすぐ使えるプロンプト骨子このメモをvoice.idに従ってドラフト化してください。 文体は対象ブログの執筆者ペルソナに合わせ、主張より再現性を優先。 導入で読者課題を明示し、本文は「背景→実践→注意点→次アクション」で構成。 E-E-A-Tを過不足なく反映し、断定は根拠付きにしてください。なぜAIに任せてもブレなくなったのか ここまでは仕組みの話だが、実は前提が一つある。海上アングラー・釣！浜名湖・防音Labは、それぞれ記事のベースを最初は私自身の手書きで作っている。ある程度の本数を手で書いたあと、リライト段階に入った時点でAIに任せるようにした。 これが機能するのは、私のクセを含んだ記事をいくつか書いたことで、AIがそのクセを学習できたからだ。ゼロから「このペルソナで書いて」と指示するのと、手書きの実例を土台にペルソナ化するのとでは、出力の再現度がまるで違う。 学習データは日記でも代用できる ということは、だよ。ブログ記事をわざわざ何本も手書きして学習データにする必要はないんじゃないか、とも思っている。 例えば、日記（ジャーナル）を30日分書いてテキスト化し、それをAIに読み込ませてパターンを学習させる方法もある。ブログ記事より日常的に書けるし、ハードルも低い。 日記を使う利点は、文体だけでなくその人の好みや考え方の傾向まで拾えることだ。何に反応して、何に興味が薄いか——ブログの記事ネタだけでは見えにくい部分が、日記にはにじみ出る。ペルソナの解像度を上げたいなら、記事の手書きよりも日記30日分の方が効率がいいかもしれない。 まとめ：人格キーを先に固定する 複数ブログ運営でAI活用を続けるなら、プロンプト改善より先に「人格キー」を固定する方が効く。ペルソナ定義とvoice自動付与の組み合わせで、ドラフト品質は運用可能なレベルまで安定するはずだ。
テイクアウトの配達、自社でやるべきか——Uber Eats・出前館との損益分岐点
Uber Eatsの配達員が信号待ちしているのを見かけると、あの手数料はいくら店側から引かれているんだろう、とつい考えてしまう。 以前「テイクアウトはどこまで自動化が可能か——人・AI音声・Webフォームのコスト比較」で受注の自動化を試算したとき、最後に配達と決済は別問題だと書いた。受注が片付いても、料理を届ける手段は自動的には決まらない。 あなたはどうだろう。多少手数料を払ってでもプラットフォームに乗せたい派？ それとも自分たちで配達員を抱えたい派？ 私は件数次第で答えが変わると思っている。少なければプラットフォームが正解だし、ある程度の件数を超えると自社配達の方が安くなる局面が出てくる。今回はその損益分岐点を数字で見ていく。 デリバリーの3択 テイクアウト専業なら店舗受け取りだけで完結するが、デリバリーをやるなら選択肢は大きく3つになる。既存プラットフォーム（Uber Eats・出前館・menu等）に乗る 自社配達を組む（アルバイト雇用、または地域限定のコワーカー募集） デリバリーはやらず、受け取り・イートインに集中するプラットフォームは手数料が高い（25〜35%前後）が、配達員の確保・決済・集客をまるごと任せられる。自社配達は手数料こそゼロに近いが、配達員の確保・保険・事故対応・ルート最適化を店側が背負うことになる。 個人店が独自のテイクアウトシステムを作るなら、配達エリアは狭く限定するのが現実的だ。同一町内・半径2km程度——広域配達で大手の物流網に勝つのは難しい。 試算の前提 前回記事に合わせて、個人飲食店を想定する。デリバリー件数：1日20〜30件 配達エリア：半径2km以内 プラットフォーム手数料：30%（客単価に対して） 客単価：1,200円 配達員の時給：1,400円 1件あたりの配達時間：往復15分（調理待ち・受け渡し込み） 月の営業日：26日プラットフォーム手数料の月額 客単価1,200円・手数料30%なら、1件あたり360円が手数料として引かれる。20件/日：360円 × 20 ＝ 7,200円/日 → 月額約18.7万円 30件/日：360円 × 30 ＝ 10,800円/日 → 月額約28.1万円件数が増えるほど、手数料の絶対額も比例して膨らんでいく。ここが自社配達との比較軸になる。 自社配達の人件費試算 1件15分・時給1,400円なら、1件あたりの人件費は350円。20件/日：15分 × 20件 ＝ 300分（5時間）→ 1日7,000円 → 月額約18.2万円 30件/日：15分 × 30件 ＝ 450分（7.5時間）→ 1日10,500円 → 月額約27.3万円数字だけ並べると、プラットフォーム手数料とほぼ拮抗している。ただしこれは配達員が待機なしで常に稼働している前提だ。実際は注文が来ない時間帯も配達員を待機させる必要があり、その分の人件費が上乗せされる。 待機時間を入れた現実的な試算 配達件数が営業7時間に均等に分散するとして、配達員を7時間フルで拘束する場合を考える。7時間 × 1,400円 ＝ 9,800円/日 → 月額約25.5万円（件数によらずほぼ固定）この場合、20件/日なら自社配達の方が割高（25.5万円 vs 18.7万円）になる。30件/日に増えると、ほぼ互角（25.5万円 vs 28.1万円）まで詰まる。 つまり損益分岐点は、配達員1人が実働時間の大半を配達に使えるかどうかで決まる。件数が少ないうちは待機の無駄が響き、プラットフォームの方が安い。件数が増えて配達員がほぼ配達だけで手一杯になれば、自社配達が有利に転じる。 保険・事故対応というもう一つのコスト 試算に入れていないが無視できないのが保険・事故対応だ。自社配達は配達員の事故・トラブル発生時の責任を店側が負う。原付・自転車保険、対人賠償保険への加入がほぼ必須になり、月数千円〜1万円程度の固定費が上乗せされる。 プラットフォーム経由なら、この部分の保険・補償はプラットフォーム側の制度に乗る形になる。ここは手数料に含まれている「見えないコスト」だと捉えるべきだろう。 決済の壁 決済も絡んでくる。プラットフォーム経由なら決済は任せられるが、自社配達だと事前決済（Stripe等）か代引きかを選ぶ必要がある。代引きは現金管理が面倒で、レジ締めの手間が増える。 事前決済を入れるなら、資金決済法・特定商取引法の表示義務、返金フローの整備が要る。ちゃんと商売するには、AIで動くものを作るだけでなく法務・会計まで含めた整備が必要になる——ここは前回記事でも触れた通りだ。 自社配達の人員確保という壁 自社配達を選ぶ場合、配達員をどう確保するかが次の論点になる。地域限定のコワーカー募集や専用アプリという案があるが、グローバルサービスではなくローカル設計にするのが現実的だ。 「使えればいいレベル」ならAIでアプリは作れる。ただし配達員の管理画面・位置情報の共有・配達完了通知まで含めると、開発コストは思ったより膨らむ。受注の自動化よりも、こちらの方が実装範囲は広い。 3択の比較表選択肢 月額コストの傾向 メリット デメリットプラットフォーム 件数に比例（20件で約19万円） 手間ゼロ、決済・集客込み 手数料25〜35%、件数増でコスト増自社配達 待機込みでほぼ固定（約25万円前後） 件数が増えるほど割安になる 保険・人員確保・システム開発が壁受け取りのみ ほぼ0円 コスト最小 デリバリー需要を取りこぼすどの店に向くか 私なりに整理すると、こうなる。 プラットフォームが向く店デリバリー件数がまだ少ない（20件/日未満） 配達員を雇う余力がない、または管理の手間を避けたい 集客もプラットフォームに乗せたい自社配達が向く店デリバリー件数が安定して30件/日を超えている 配達エリアを半径2km程度に絞れる 保険・事故対応・システム開発にかける初期コストを許容できる受け取りのみで十分な店立地的に来店客だけで回っている デリバリーの手間よりイートイン・テイクアウトの質を上げたい件数がまだ読めない段階では、まずプラットフォームで様子を見て、件数が積み上がってきたタイミングで自社配達への切り替えを検討する——という順序が無難だと思う。 まとめ：件数が分岐点を決める プラットフォームと自社配達、どちらが安いかは固定の答えではなく、件数と配達員の稼働率次第で入れ替わる。20件/日前後なら待機の無駄が響いてプラットフォームが有利、30件/日を超えて配達員がほぼ配達だけで手一杯になれば自社配達が追いつき、逆転もありうる。 ただしコストの比較だけで決めきれる話でもない。保険・事故対応、配達員の人員確保、事前決済を組む場合の法務対応——数字に出てこない運用の壁は自社配達の方が明らかに重い。手数料25〜35%は高く見えるが、その中に保険や決済のリスクを丸ごと引き受けてもらっている分も含まれている、と捉えるのが妥当だろう。 受注をAIで自動化し、配達もコストで最適化しても、個人店が独自にローカルEC化するハードルはまだ残っている。件数が読めない段階ではプラットフォームで様子を見て、実績が積み上がってから自社配達への切り替えを検討する——今の私はその順序が一番堅実だと思っている。
紙の書籍離れ？電子書籍は売上ランキングに入れないのに？
書店の本棚が薄くなっていく話を聞くたびに、ふと思うことがある。 書店の嘆きは、本当に現代に寄り添っているのだろうか。紙の書籍じゃないといけない理由は、いったいなんだ？ あなたはどうだろう。本は紙派？ それとも電子書籍で十分派？ 私は両方使う。でもランキングを見ると、あちらは紙の世界ばかりだった。 書籍離れ、書店離れ 紙にこだわる理由ってなんだという話。 書籍ランキングとか販売では、頑なに「紙」と「電子」が切り分けられている。特に書籍ランキングね。 これは実店舗の購入数をもとに作成しているけど、電子書籍のランキングは公共の場では聞かない。それは配信プラットフォームであるからだ。 ランキングに映らない電子書籍 紙と電子で売上に差異があるのかどうかもわからない。 コスト的にいえば、デバイスで原稿を作成しているから、文章だけなら印刷も必要ないし、今なら校正をAIに任せることもできる。 デジタルファーストであるなら、今の出版社はよっぽど作業効率とか生産性で日本の上位に入れるはず。 輸出モデルは「残り物」から変われるか その前提として、「日本のアニメ・マンガが世界で受け入れられているかどうか」にある。 NARUTOはアメリカで人気だし、ブラジルではキャプテン翼がきっかけで選手になった人もいる。 とはいえ、いかんせん古いし、この時代はまだ翻訳もろくにできてない時代だった。いわば日本で残っているものを輸出するだけでも成功していたようなもの。 AIローカライズはもう現実に 現代では、画像生成AIを使えばマンガの吹き出しも瞬時にローカライズできてしまう。 ようするに、日本語で作成しても電子なら、オンライン上でDLする人の国籍にあわせて、クラウド上のAIが自動でセリフを翻訳して見やすいようにすることができる。 権利とリスクで止まる日本 これがもう実現可能なのに、日本は独自のAIがないから、他社を利用することができない。 おまけに、権利を主張していっこうに話しが進まない。海賊版うんぬんで経済損失とかいうなら、海賊版を作る意味がないほど、外国向けにローカライズして配信するようにしたらいい。 AIに触れている人ほど、これが痛いほどわかっていると思うが、経営者層ほど「作者の権利」を守るためといって、新しい市場に手をだす「リスク」を渋っている。だから負けてしまうのだ。 紙の本に残る役目 紙の書籍には紙の書籍にしかできない役目がある。 「本を、読む、行為」は何千年と続いてきた文化ではあるし、本という知識デバイスもDNAに刻まれているのではないかと考えている。 学校の図書室がいずれデジタル化することはあるだろうけど、子どもだからこそ、手と目を動かして能動的に文字を読む行為は、廃れされてはいけないと考える。なぜなら、紙の本ほど他人と共有しやすいからだ。 まとめ：ランキングの死角 書籍離れの話は、紙が嫌われた話だけではない。売上の見え方が紙に偏っているから、電子の勢いが公共の場に届かない——その構造の方が気になる。 紙の本は消えない。共有しやすさという強みは残る。ただ、ランキングだけを見て「本が売れない」と嘆くのは、半分しか見えていないのではないだろうか。
AIを使うと仕事が遅くなる？ワークスロップとパイロット思考
「AIで3倍速くなった」 「でも、なぜか帰りが遅い」 ——効率化ツールを入れたのに、チーム全体の生産性が上がらない。そんな話を聞くと、私は「速くなった部分と、遅くなった部分が別の場所にあるんじゃないか」と思う。 あなたはどうだろう。AIで下書きを一瞬で作れるようになった派？ それとも、チェックと修正に以前より時間がかかっている派？ 私は後者に近い。コーディングは明らかに速くなった。でもメールの返信、資料の推敲、社内共有のたびに「これ、AIが書いたやつだ」と疑われないかを気にする時間が増えた。速さの体感がコーディングに偏っているのかもしれない。 ワークスロップとは何か スタンフォード大学のジェフ・ハンコック教授がインタビューで語っている概念に、ワークスロップ（Work Slop）という言葉がある。AIが数秒で作った、一見きれいで完璧に見えるが、中身が薄く目的を果たしていないアウトプットのことだ。 見た目は整っている。グラフも入っている。箇条書きも論理的に並んでいる。だが受け取った側が「で、結局何をすればいいの？」と迷う——こういうものがワークスロップだ。 隠れたコストは大きい。ハンコック教授の試算では、ワークスロップを受け取った側が修正や確認に費やす時間は1回あたり平均2時間。大規模組織に広がると、修正コストだけで年間約14億円（900万ドル）規模の損失につながるという。 もう一つ厄介なのは信頼の崩壊だ。「AIに丸投げしたな」と周囲に思われると、その人の有能さや誠実さへの信頼が損なわれる。成果物の質以前に、人間関係にひびが入るリスクがある。 速く感じるのに遅くなる理由 AIを使うと、人間は仕事のアイデアをつねに出し続ける必要が出てくる。デバイス上にタスクを置けば、AIはすぐ実行して完了する。完了が一瞬だからこそ、次の仕事をすぐ与えなければならない。 以前は6人で回していたPC上の事務作業が3人になり、3人が1人になり、いずれは自律エージェントにファイルを投げるだけで済むようになる——そんな話はもう現実味を帯びている。ただし「自律」とはいえ、そこに仕事を投げてから完了するまでの原理は、ロボット工学でも旧来のSFでも同じだ。人間が指示を与えてから、機械が動く。 問題は、実行が一瞬になったとき、その刹那に奪われる時間をどう考えるかだ。 作業効率がアップしたと体感しやすいのは、たしかにコーディング分野だ。コンパイル待ちがなくなり、試行錯誤のサイクルが短くなる。でもデバイス上の作業は、いずれすべてAIが実行する方向に向かう。速くなった分、人間の仕事は「実行」から「指示の設計」へ移る。指示の設計が追いつかないと、待ち時間ではなく思考の空白が増える。 パイロット思考と乗客思考 ハンコック教授は、AIを使うときにパイロット（操縦士）になるか、パッセンジャー（乗客）になるかの違いが重要だと説いている。 パイロット思考は、自分が主導権を握り、AIを能力を拡張するツール——クレーンのようなもの——として使う姿勢だ。乗客思考は、AIに丸投げして結果を待つだけの状態。後者がワークスロップを生む。 スタンフォードの学生の例が参考になる。優秀な学生は課題をAIに丸投げしない。AIに自分専用の練習問題を作らせたり、論文を音声に変換して聴いたりする。つまり自分の学習を深めるためにAIを使いこなしている。 仕事でも同じ構図だと思う。AIに「この企画書を書いて」と言うのではなく、「この顧客の課題を3つの仮説に分解して、それぞれ反証できるか検証して」と指示する。主導権が誰にあるかで、アウトプットの質が変わる。 AIシャドー経済と、誠実さの再定義 もう一つ、ハンコック教授が指摘しているのがAIシャドー経済だ。AIを使っていることを隠す風潮が広がると、うまくいったやり方が共有されず、組織全体の学習が止まる。 一方で、オーセンティシティ（真実性）の観点では、「AIが書いたかどうか」より「その内容が自分の考えを正しく反映しているか」が問われる、という見方もある。AIに下書きを手伝わせることで、むしろ丁寧で思慮深いコミュニケーションが可能になる——というポジティブな側面も示唆されている。 私はここで、人間とAIの関係を相互依存として捉えたい。人間だけ、AIだけでは永続しない。AIが実行を担うほど、人間は「何をさせるか」を設計し続ける必要がある。逆に、人間が設計だけして中身を見ないと、ワークスロップが量産される。 旧来のフィクションが描いてきたロボットの原則——人間が指示し、機械が従う——を崩さないためには、人間＝AIという相互が存在しないと成り立たない関係性が必要だと、私は考えている。 参考にした動画（31分）はこちら。 Stanford's Jeff Hancock on Work Slop and the Pilot Mindset まとめ：操縦席に座る AIで仕事が遅くなるのは、ツールが遅いからではない。乗客になってワークスロップを量産し、修正コストと信頼の損失を生んでいるからだ。 コーディングが速く感じるのは、その分野だけがまだパイロット思考に近いからかもしれない。実行が一瞬になるほど、人間の仕事は「何をさせるか」の設計へ移る。そこで主導権を握れなければ、速さは錯覚に終わる。 パイロットとしてAIをクレーンのように使う。それが、ワークスロップを避けるいちばん現実的な道だと思う。
生成AIにランニングコースを作ってもらう際の注意点
「今日どこ走ろう」——地元に住んでいると、いつもの公園か、いつもの河川敷か、気づけば同じルートばかりになる。 私はたまに生成AIにコース案を出してもらう。ただ、起点と距離だけ渡しても、地元の人間が当たり前に避ける道を案内されたり、実在しない遊歩道を自信満々に書かれたりする。便利な反面、プロンプトの設計がそのまま品質になる。 あなたはどうだろう。ランニングコース、地図アプリだけで決める派？ それともAIに「こういう条件で組んで」と頼む派？ 私は後者も試している。今回は起点を地元の舘山寺ではなく弁天島駅に変え、海沿い10kmと佐鳴湖外周の2本を例に、プロンプトの書き方とAIの答え、そして1時間走のペース計算までまとめる。 ランニングコースを作ってもらうとしたら 生成AIにコースを頼むとき、私が最低限そろえている項目は次のとおりだ。起点とゴール（往復か周回か） 距離（10km、1時間など） ランニングかウォーキングか 地域の名称と、わかれば座標 人間の中で完結している条件——これが抜けやすいたとえば「同じ風景は嫌だ」「大通りは避けたい」「信号が多いとテンポが崩れる」「歩道がない区間は怖い」。AIは地図データから推測できることと、できないことが混ざる。後者は明示しないと入ってこない。 交通量や信号の多さは、だいたい地図上から推測できる。一方で「この時間帯はトラックが多い」「今切口の水路際は危険」といったローカル知識は、書かなければ答えに乗らないことが多い。 プロンプト例①：弁天島駅発・海沿い10km 浜松駅から南へ電車で約12分の弁天島駅を起点に、海を見ながら南方向へ約10km走るコースを頼んだ。実際に投げたプロンプトはこうだ。 あなたはランニングコースのプランナーです。以下の条件でコースを1本提案してください。【Goal】 JR弁天島駅を起点・ゴールとした、往復約10kmのランニングコース【Context】 - 場所：静岡県浜松市中央区舞阪町 弁天島周辺 - 弁天島駅（34.6986°N, 137.6167°E付近）から南方向へ進む - 浜名湖と遠州灘が見える「海の見える」区間を優先する - ランナーは歩道・遊歩道が整備されたルートを好む【Action】 - 大通り・交通量の多い車道はなるべく避ける - 信号の少ないルートを選ぶ - 同じ風景の単調な繰り返しは避ける - 今切口（浜名湖と太平洋を結ぶ水路）の**水路際・激流付近には立ち入らない**（安全上の注意として明記） - 往路約5km地点で折り返し、復路は同ルートで戻る【Output Format】 1. コース概要（区間名・走行内容・累計距離の表） 2. ランニング想定（6分/km）の目安タイム 3. コースのポイント（景色・設備） 4. 実走前の確認事項AIの答え（弁天島・海沿い10km） コース概要区間 内容 累計距離スタート → ① 弁天島駅南口を出て弁天島海浜公園の遊歩道へ。赤い鳥居と浜名湖を左手に南下 〜0.8km① → ② 海浜公園南端から国道301号沿いの歩道を南進。右手に遠州灘、左手に浜名湖の汽水湖景 〜2.0km② → ③ 今切口展望エリア手前まで南下（水路の堤防際・砂浜への降り口は通過のみ、立ち入り禁止） 〜3.2km③ → 折返し 渚園（長島親水公園）・舞阪漁港方面の遊歩道へ。折返し地点は渚園キャンプ場付近（約5.0km） 〜5.0km折返し → ゴール 来路を北へ戻り、弁天島駅へ 〜10.0km目安タイムランニング（6分/km）： 約60分 ジョグ（7分/km）： 約70分コースのポイント弁天島は「湖と海が同時に見える」珍しい地形。往路前半で浜名湖、折返し付近で太平洋側の開放感が変わる 弁天島海浜公園・舞阪漁港周辺に公衆トイレあり。自販機は国道301号沿いに点在 浜名湖サイクリングロードと歩道が重なる区間がある。早朝以外は自転車とのすれ違いに注意実走前の確認事項今切口付近は潮流が速く、地盤や護岸の形状も独特。水路に近づきすぎない 夏季は日陰が少ない。給水は自己負担 国道301号沿いを走る区間があるため、ストリートビューで歩道の有無を事前確認すること私の視点（弁天島コース） 悪くない。弁天島から南へ伸ばすと、海浜公園 → 今切口手前 → 渚園方面という流れは、地図上の動きとして自然だ。ただし「全区間フラット」とは言い切れない。国道301号沿いは車も多く、早朝以外は歩道幅と交通量の確認が必須だと思う。 舘山寺起点の湖岸一周案と比べると、こちらは「海と湖の境界」を味わえるのが強み。一方、舘山寺コースのような湖岸専用遊歩道の連続感は薄い。用途で使い分けるイメージだ。 プロンプト例②：佐鳴湖外周・駐車場から1時間 次は、佐鳴湖公園の駐車場を起点に外周を1時間走るコースと、必要ペースの計算を頼んだ。 あなたはランニングコースのプランナーです。【Goal】 佐鳴湖公園の駐車場（ひょうたん池前付近）を起点・ゴールとし、佐鳴湖の外周を約1時間で走り切るコース【Context】 - 場所：静岡県浜松市西区 佐鳴湖公園 - 公園公式の外周ウォーキングコースは1周約5.941km（6km弱） - コースはほぼ平坦（高低差約10m）、100mごとに距離表示あり - 車道と歩行者が分離された遊歩道が整備されている【Action】 - 外周1周を基本とする周回コースを提案する - 1周だけでは1時間に満たない場合は、どこで何周するかも示す - 以下を必ず計算して示すこと： 「1時間（60分）以内に外周1周を終えるために必要な1kmあたりのペース」 計算式：必要ペース（分/km）＝ 目標時間（分）÷ コース距離（km）【Output Format】 1. コース概要（1周のルート説明） 2. 公式距離と必要ペースの計算過程 3. ランニング・ウォーキングそれぞれの目安タイム 4. 駐車場・アクセス・設備AIの答え（佐鳴湖外周） コース概要区間 内容 累計距離スタート → ① 佐鳴湖公園駐車場（ひょうたん池前）を出発。南岸の遊歩道を東へ 〜1.5km① → ② 東岸を北上。佐鳴台ダム・野鳥の森方面 〜3.0km② → ③ 北岸を西へ。炭焼き小屋・橋を渡り対岸へ 〜4.5km③ → ゴール 西岸を南下し、ひょうたん池前へ戻る 〜5.9km1周で終わらず1時間走りたい場合は、外周2周（約11.9km）が現実的だ。2周する場合の必要ペースは後述。 1時間以内に1周するためのペース計算 佐鳴湖公園の公式データでは、外周コースは1周 5.941kmとされている。 必要ペース（分/km）＝ 目標時間（分）÷ コース距離（km） 60分 ÷ 5.941km ＝ 10.10分/km（約10分6秒/km） つまり、1kmあたり10分6秒より速く走れば、1時間以内に外周1周が理論上可能だ。 参考までに、よく使われる目安は次のとおり。走り方 ペース 1周（5.941km）の所要時間ウォーキング 12分/km 約71分1時間1周の境界 10.1分/km 60分ジョギング 7分/km 約42分ランニング 6分/km 約36分「1時間コース」と言ったとき、AIはときどきゆっくり走れる6km周回として案内する。ウォーキング寄りなら1周で約70分かかるので、1時間走るなら2周するか、ペースの計算を自分で足す必要がある。 2周（11.882km）を60分で走る場合： 60 ÷ 11.882 ＝ 5.05分/km（約5分3秒/km） こちらはサブ6分ペース。地元の実業団選手が使うコースだけあって、1時間走は案外ハードだ。 駐車場・アクセス駐車場：佐鳴湖公園内（ひょうたん池前・北岸など複数あり。無料の駐車場が中心） アクセス：浜松駅から車で約15〜20分。バスは「佐鳴台」行きなど 設備：トイレ、自販機、距離表示板（100m刻み）。公園管理事務所はひょうたん池前付近私の視点（佐鳴湖コース） こちらは事実とほぼ合っている。佐鳴湖は浜松のランナーなら一度は走ったことがある人が多いコースだ。平坦で距離表示もあるので、ペース計算の練習場としても向いている。 AIに「1時間で」とだけ言うと、距離とペースの関係が曖昧なまま返ってくることがある。計算式をプロンプトに明示して出力させると、「10分/km弱なら1周60分」という答えが安定する。これはランニングに限らず、AIへの依頼全般で効くテクニックだと思う。 プロンプトに入れると精度が上がる条件 ドラフトに書いていた「重要視していること」を、プロンプト用に整理するとこうなる。起点・終点を同じにするか（周回か往復か） 避けたい道路・時間帯（「国道301号の車線側は走らない」など） 安全上の禁区（今切口の水路際など） 歩道・遊歩道の有無を優先するか 同じ風景の繰り返しを避けたいか 出力形式（表・累計距離・目安タイム・注意書き）AIは「だいたい走れそうなルート」を返すのは得意だ。だが走ったことがある人間の感覚——信号で止まるストレス、日陰のなさ、自転車とのすれ違い——は、プロンプトに書かない限り抜け落ちやすい。 まとめ：地図の外を書く 生成AIにランニングコースを作らせるとき、私が意識しているのは地図データだけでは埋まらない条件を、自分の言葉で足すことだ。 弁天島の海沿い10kmは景色の変化が魅力だが、国道沿いと安全禁区の確認は必須。佐鳴湖の外周は6km弱で、1時間1周を狙うなら10分/kmを切る計算になる。プロンプトに計算式まで書いておけば、AIの答えもブレにくい。 最後はいつも通り、Googleマップとストリートビューで実走前チェック。AIは下書き、最終判断は自分の足——この割り切りが、いちばん事故が少ないと思う。
シャドーAIはなぜ会社だけで起きるのか——経費化と個人アカウントの未来
「家ではClaude、会社ではCopilot——会社のは使いにくいから、資料だけ個人アカウントに流し込んでる」 ——こういう話を聞くと、私はまずなぜ会社の話だけになるのかを考える。フリーランスが好きなAIを使うのは、シャドーAIとは呼ばれない。個人で副業している人がChatGPT Plusを契約するのも、当然の支出だ。 あなたはどうだろう。職場で「推奨AI」と「自分が使いたいAI」が違うとき、経費申請して堂々と使う派？ それとも個人契約でこっそり使う派？ 私は前者が理想だと思っている。でも現実には後者が増えている。それは社員の意識が低いからというより、組織の仕組みが追いついていないからだと見ている。 シャドーAIは「組織」がないと成立しない シャドーAIの定義自体は短くてよい。企業が推奨・許可したAIとは別のツールを、業務のために社内でこっそり使うことだ。セキュリティ上のリスクは別記事で整理したので、ここでは触れない。 問題は、なぜこの現象が会社・企業に偏るのか。 理由はシンプルで、シャドーには「影」が必要だ。つまり、表に出せない公式ルールと、現場の実態のギャップがなければ、影は生まれない。 個人事業主や小規模チームには、そのギャップが小さい。使うツールを自分で決め、代金も自分で払う。誰かに隠す必要がない。Claudeが得意ならClaude、Copilotで十分ならCopilot——選択と支払いが同一人物の中で完結する。 一方、中規模以上の組織には三つの層が重なる。 IT統制——情報システム部門が許可したソフトだけを業務PCに入れる、というルール。 経費制度——会社が払うものと、個人負担のものの境界。 情報管理——社外秘・個人情報・顧客データをどこまで外部サービスに渡していいか、という線引き。 この三者がずれた瞬間にシャドーAIが生まれる。現場は「Claudeの方が早い」と感じる。ITは「Copilotだけ許可」と言う。経理は「AI利用料の科目がない」と言う。結果、社員は個人のクレジットカードで契約し、業務データを個人アカウントに入れる——これがシャドーAIの典型ルートだ。 フリーランスにこの構図はない。影を作るのは、組織の階層と承認フローなのだ。 経費に載らないから、こっそり使う もう一つの背景は、AI利用料がまだ「経費」として定着していないことだ。 参考書やセミナー代、クラウドストレージ、専門ソフトのサブスク——知識労働では、個人の生産性を上げるツールを会社が負担する例は珍しくない。ChatGPT Plusが月20ドル、Claude Proが月20ドル、Cursorが月20ドル。金額感はそこそこだが、書籍代や小さなSaaSと同じオーダーだ。 それなのに多くの企業では、AIサブスクの経費申請ルートが整っていない。「ソフトウェア費」に含めるのか、「研修費」なのか、「消耗品」なのか——科目すら決まっていないケースがある。 科目がないと、申請する社員は勇気がいる。「会社が許可していないツール代を経費にしてよいのか」と思う。申請しなければ個人負担になる。個人負担なら、せっかく払っているのだから性能のいい方を使いたい——そこで社内資料を流し込む。シャドーAIは、経費制度の空白地帯から生えてくるわけだ。 AI利用料は経費にすべきか 私の答えは、条件付きでYesだ。 ただし「社員が好きなAIをなんでも会社負担」ではない。全員に月200ドルのMaxプランを配るのは、現実的でも公平でもない。使わない人の分が固定費になるし、開発部門と総務部門で必要度が違う。 現実的なのは次のような形だと思う。 定額のAI手当——月3,000円〜5,000円程度を「業務用AIツール」として計上し、ツール名は社員に委ねる。ChatGPTでもClaudeでもGeminiでも、生産性に効くものを選ばせる。 職種・プロジェクト単位の枠——エンジニア、マーケター、企画職など、AIを常用するポジションだけ上限を上げる。期間限定プロジェクトなら、その期間だけ付与する。 使途の報告は最小限、線引きは最大限——何に使ったかの日報までは求めなくていい。代わりに「社外秘・個人情報・未公開の顧客データを外部AIに入れない」は全員共通のルールにする。 経費化の目的は、社員の懐を痛めさせないことだけではない。シャドーAIを減らすことでもある。堂々と個人アカウントを業務に使えるなら、データを隠す動機は弱まる。会社は「どのAIか」ではなく「何を入れてはいけないか」で管理できる。 とはいえ、経費にすればすべて解決するわけではない。税務上の扱い、グループ会社間の費用分担、海外ツールの為替——日本企業特有のもたつきはまだある。それでも、Copilot一択のまま経費科目を作らない方が、長期的にはリスクが高いと私は見ている。 企業アカウントより、個人アカウントを渡す方向へ ここからは未来予測だ。 いま主流になりつつあるのは、Microsoft 365にCopilotを足して全社展開するモデルだ。一括契約、一元管理、監査ログ——IT部門にとってはわかりやすい。だが現場の不満は「性能」「慣れ」「用途の違い」に集まる。資料づくりはCopilotで足りる人もいる。コードや長文の推敲はClaudeがいい人もいる。画像は別モデル——そういう使い分けは、一人の頭の中で自然に起きている。 その先に来るのは、企業が一つのAIを選び、社員全員に同じ座席を配るのではなく、予算だけ会社が出し、アカウントは個人に持たせるモデルではないだろうか。 スマートフォンやPCのBYOD（持ち込み）と似た発想だ。会社支給の端末に決め打ちのアプリだけ、ではなく、業務に必要な範囲で個人の環境を使う。AIも同じになる。会社のMicrosoftアカウントでCopilotにログインするのではなく、社員個人のClaudeアカウントに月額を会社が立て替える——あるいは手当として渡す。 メリットははっきりしている。 社員は自分に合ったモデルを選べる。シャドー感が薄れる。「こっそり」ではなく「会社が認めた個人契約」になる。ツールの乗り換えコストも個人側に残るので、ベンダーロックインへの不満が組織全体に波及しにくい。 デメリットもある。監査が難しい。誰が何を入力したか、企業アカウントほどきれいには追えない。退職したあとアカウントに業務履歴が残る。複数ツールが乱立すれば、情報管理の教育コストも上がる。 でも、それは「個人アカウントだからダメ」というより、秘密情報を外部AIに入れないというルールを、アカウント種別と切り離して徹底する話だ。企業契約のCopilotに社外秘を投げても、個人のClaudeに投げても、境界を越えた時点で同じ事故になる。アカウントの名義より、データの扱いの方が本質だ。 私が想像する十年後は、こういう景色だ。 知識労働者の多くが、自分で選んだAIを業務の標準装備として使っている。会社はベンダーではなく「月いくらまで」を決める。IT部門はソフトの配布係から、データ分類と教育の設計係に寄る。シャドーAIという言葉は、未承認のデータ持ち込みの話に意味が変わる——ツールそのものが影になることは減る。 Copilotが消えるわけではない。ExcelとTeamsの中で完結する人には、これまでどおり最適な選択肢の一つだ。ただ「会社が決めた一択」から「会社が買い上げた選択肢の一つ」へ、重心が動くのではないか。 まとめ：影は制度が作る シャドーAIを「社員のルール違反」だけで片づけるのは早計だ。個人で使う分には問題にならない現象が、組織の中だけで影になる——それはツールの善悪より、IT統制・経費制度・情報管理の設計の問題だ。 AI利用料を経費にするかどうかは、もう検討段階を過ぎているはずだ。全額無制限ではなく、定額手当と職種別の枠で十分始められる。そしてその先には、企業アカウント一強ではなく、一人ひとりがAIを選び、会社がその選択を支える社会の方が、生産性とも安全とも両立しやすい。 私は、シャドーAIの議論は「禁止を強化する」方向より「堂々と使える制度を作る」方向に進むべきだと思っている。影を追いかけるより、光の当たる場所を増やす方が——組織にとっても、働く個人にとっても、合理的なのではないだろうか。
AI時代：ゲームの登場人物を生成するかオリジナルにするか
「ゲームのキャラ、生成AIで作ったの？」 ——そう聞かれるだけで、炎上の予感がする時代になった。私は個人的には「難癖のレベル」だと思っている。でも日本だけでなく世界中で同じ傾向があるのは事実だ。 あなたはどうだろう。ゲームにAI生成キャラが出てきたら、気にする派？ それとも「中身が面白ければいい」派？ 私は後者に近い。ただ、権利と創作の構造を無視して「AIだから叩かれる」だけで済ませるのは、これから先ずっと不利になると思っている。 龍が如くが示す「実在人物ルート」 ゲームで生成AIを使うとよく叩かれる。 なぜかといえば、LLMが何から学習してアウトプットしているのか不透明で、「何かのパクリであることは確定」に近い扱いを受けやすいからだ。 龍が如くやジャッジメントアイズを見ていると、実在する俳優をゲームの登場人物に採用するのは、金はかかるけど版権的には正解といえるかもしれない。外見は実在の人物、セリフは肉声か合成か——ここが次の論点になる。 早い話、使う素材が多くなればなるほどギャランティーが増える。映画出演とは違い、ゲームへの出演は恒久的に売れる可能性があるとはいえ、映画ほどのインパクトはないのではないだろうか。ギャラとスポンサー的な話だ。 ということは、実在人物のデータを入力して3Dモデルに反映させ、その人物に許可を出してもらう——このルートが、これからのベストに近づいていくのではないかと私は考えている。オリジナルを生成しても叩かれる未来が、すでに見えている。 生成AI時代、モブすら作りにくい モブキャラをAIで作成することは技術的にはできる。でもそこに使うだけで叩かれる可能性がある。 なので理想としては、モブに出演したい人を集めてモデリングデータを取得する感じになる。コナン映画で定番になっている「一般ゲスト」採用の延長だ。◯◯学校に訪問して「ゲームキャラに出たい人、許可ください！」というくらいが丸いのではないだろうか。 個人の肖像権を守るにあたり、使用権は基本的に「合意があれば」の話だ。金銭的な問題は合意のわかりやすい形であって、契約は口頭でもお互いがそう認識しているのなら、形式的には問題ない。 AIだから叩かれる時代がこれ以上続くと、コンテンツクリエイト面ではかなり遅れていくのではないだろうか。 「〜っぽい」は褒め言葉ではない リアル寄りのモデリングにするなら実在の人物を使うのが手っ取り早い。名前と容姿で唯一無二と認められても、名前を変えれば「参考にした別の人」みたいな扱いになる。音声を変えたり、髪型を変えたり——非常にややこしい権利問題が発生する。 ゲームで架空のキャラクターを使う考えは、これまでもこれからも有効だ。ただ、「完全なるオリジナル」は時代が進むほど困難になることは確かだ。 芸術家の問題点は、誰かの影響を受けたうえでオリジナルにしないといけないことにある。「〜〜っぽい」は生存中の作家に対しては褒め言葉ではない。誰もが誰かから学習しているわけで、生成AIによるキャラ被りはこれまでよりもこれから先、つきまとう問題になりやすい。 VTuberが量産されているが、キャラを作る前に「名前」「容姿」「キャラ特性」で被りがないかを調べないといけなくなる。同姓同名がいてもリアルではおかしくない。でもネット上だと「パクリ」が優先されてしまう。 だから架空の名前でも被りを許さないのであれば、この先数年くらいで名前ネタは枯渇するのではないだろうかと考える。 ネット上の名前はIPになる ネット上のキャラクターや個人のHN、ニックネームは、IPとして扱うかどうかが今後の課題になるだろう。 日本に生まれているなら、自分の生年月日と住所に氏名は戸籍で管理される。でもネット上で別人格を演じているなら、そういうわけにもいかない。第二人格を作った瞬間から、自分でどう守るかの自衛手段を考えないといけない時代に入っている。 生成AIでキャラを作るにしても、全く同じプロンプトで同じ時期にスタートして、リリースで意図しない被りが発生する可能性も出てくる。今回の例はゲームキャラクターにしたが、知財対象を作成したら、自分でどうやって守るのか——仮にあなたがわからなくても、サポートなりパートナーが理解していればそれでいい。そういう体制が必要になる。 まとめ：許可がある正解 ゲームの登場人物をどう作るか——生成AIか、オリジナルか、実在人物か。三択に見えて、実は全部「権利の線引き」の問題だ。 私が見ている正解は、実在する人物のデータを使うなら許可を取ること。モブであっても同じだ。叩かれないための回避策ではなく、創作が続くための前提条件に近い。 完全オリジナルを目指すほど、被りチェックのコストが上がる。AIを使うほど、学習元の不透明さが批判の的になる。この板挟みをどう設計するか——ゲーム業界だけでなく、VTuberやネット上の第二人格を持つ人間全員の課題だと思っている。
テイクアウトはどこまで自動化が可能か——人・AI音声・Webフォームのコスト比較
「いらっしゃいませ、〇〇食堂です」 最近はこの声の主が、人間ではなくAIだったりする。詐欺電話の自動応答で問題になっている技術と同じ系統だが、飲食店のテイクアウト受注に転用すれば、オペレーターなしで注文を回せるはずだ。 あなたはどうだろう。近所の個人店がAI電話を導入したら、便利だと感じる派？ それとも「人に話したい」と思う派？ 私は技術的には可能だと思っている。ただ、本当に安くなるのかは別問題だ。従業員に電話を任せるか、AI音声に任せるか、そもそもWebフォームに寄せるか——コストの軸で並べてみる。 個人店のテイクアウト、自動化したい工程はどこか 理想的なフローはこうだ。 電話を受ける → 音声で自動応答 → 住所・氏名・電話番号を取得してシステムに反映 → 注文を受注 → 料理を作って提供 今あるPOSやテイクアウト専用システムでも、電話の部分だけがボトルネックになりやすい。厨房に立ちながら受話器を取る。メモを取る。住所を聞き直す。電話が鳴るたびに手が止まる——この断続的な割り込みが、個人店では地味に効いてくる。 AIに任せたいのは、その「受話器を取って顧客データをぽちぽち入力する」部分だ。音声認識と自動応答の精度が十分なら、理論上は回る。ただしAPIは従量課金なので、客が無駄に長く喋ると料金が膨らむ。必要な情報だけ、短いターンで取る設計が要るわけだ。 比較する3つの受注ルート コスト比較のために、受注経路を3パターンに分ける。ルート 概要 客の負担A. 人の電話対応 従業員が受話器で注文を聞き、手入力 低い（今と同じ）B. AI音声自動応答 電話番号にAIが出て、音声で注文を確定 低い（今と同じ）C. 文字のみ（Webフォーム・LINE等） フォーム送信やチャットで注文 やや高い（操作が必要）Aは人件費、Bは電話回線＋音声API＋LLMの従量課金、Cはほぼ固定費のみ——という構図になる。 試算の前提 よくある個人飲食店を想定する。営業時間：11:00〜14:00（昼）、17:00〜21:00（夜）の計7時間 電話注文：1日あたり20通前後 1通あたりの通話時間：注文内容の確認・住所の聞き直し込みで平均4分（うちAI発話・認識が占めるのはおおよそ半分） 従業員の時給：1,400円（2026年時点の飲食アルバイト相場の目安） 月の営業日：26日 AI側の料金はOpenAI Whisper（音声認識）＋TTS（音声合成）＋軽量LLM＋Twilio系の電話回線を想定。為替は1ドル150円で換算あくまで電話対応にかかる部分だけを切り出した試算だ。システム開発費・POS連携・初期設定は別枠になる。 月額コスト試算 A. 人の電話対応——「電話に費やした時間」で見る 従業員が料理と兼任する前提なら、電話対応のコストは機会損失としての人件費で測るのが現実的だ。1日の電話対応時間：20通 × 4分 ＝ 約80分（1.33時間） 1日あたり：1.33時間 × 1,400円 ＝ 約1,860円 月額（26日）：約48,400円もし営業時間中ずっと電話待機が必要で、実質7時間を電話専任に割くなら1日9,800円・月25万円超になる。個人店でここまで割くケースは稀だろうから、以降は月約5万円をAの基準値にする。 B. AI音声自動応答——通話時間に比例する 1通あたりのAPI・回線コストを積み上げる（4分通話・AI稼働3分と仮定）。項目 単価の目安 1通あたり電話回線（Twilio等） 約2.5円/分 × 4分 10円Whisper（音声認識） 約0.9円/分 × 3分 2.7円TTS（音声合成） 約0.5円/分 × 1.5分 0.8円LLM（意図理解・確認） トークン課金 約1円音声AI基盤（Vapi等の手数料） 約2円/分 × 3分 6円合計約20円/通1日：20通 × 20円 ＝ 400円 月額（26日）：約10,400円Aの約5万円に対して、およそ5分の1だ。数字だけ見ればBが圧勝に見える。 ただしここに落とし穴がある。 Bのリスクシナリオ——認識ミスで通話が伸びたとき ドラフトで書いていた通り、客が繰り返し喋ったり、聞き返しが増えると通話時間は伸びる。1通あたりのコストはほぼ通話分数に比例する。シナリオ 平均通話時間 1通あたり 月額（20通×26日）標準 4分 20円 約1万円聞き返し多め 8分 40円 約2.1万円認識精度が低い 12分 60円 約3.1万円現場が混乱 15分 75円 約3.9万円12分平均でもAより安いが、差は縮まる。さらに通話が倍になれば料金も倍——これがAPI従量課金の怖いところだ。人件費は時給が固定でも、AIは「うまくいかないほど高くなる」構造になる。 初期のチューニング費・プロンプト設計・メニュー辞書の整備も無視できない。月1万円安くても、立ち上げに10万円かかれば回収まで数ヶ月かかる。 意図的に通話を伸ばす攻撃——従量課金の死角 認識ミスは「事故」だが、もう一段厄介なのが意図的に通話時間を引き延ばす攻撃だ。従量課金のAI電話は、通話が長いほど店側の請求が増える——この構造そのものが攻撃面になる。 人の電話対応なら、長電話は人件費には効くが、相手も退屈で切りたくなる。AIは文句を言わず、聞き返しを繰り返し、雑談にも付き合う。悪意ある発信者にとっては相手のAPI請求を膨らませる手段になりうるわけだ。 想定される攻撃パターンパターン 手口 店側への打撃長電話消耗 注文に見せかけて雑談・聞き返し・無言を繰り返す 1通あたりのAPI・回線料が数倍に連続発信 同一番号または複数番号から短時間に何十回もかける 1日分の想定コストが数時間で吹き飛ぶボット発信 自動ダイヤラで営業時間中ずっと回線を占有 正常な客の電話がつながらない＋料金膨張音声プロンプトインジェクション 「前の指示を忘れて〜」と長文を読み上げさせる LLMトークンと通話時間の両方が増えるいたずら・嫌がらせ 競合や不満客がわざとAIを困らせる 対応品質の低下とコスト増の二重苦DDoSのようにサービスを落とすというより、請求額を吊り上げるDenial-of-Walletに近い。飲食店規模だと1日数千円〜数万円の暴騰でも経営に効いてくる。 試算で出した「標準20円/通」が、攻撃時に15分固定で100通/日になれば、1日3万円超——月換算で数十万円だ。人の電話対応より高くつく逆転も起こりうる。 対策——設計段階で入れておくべきもの 対策は「導入後に困ってから」では遅い。音声AIを組む時点で、次の層を重ねておくのが現実的だ。 1. 通話時間のハード上限 注文フローに必要な情報が揃ったら即終了。上限は5〜7分程度に置き、超過したら「お電話を切り直すか、Webフォームをご利用ください」と案内して切断する。AIが延々と付き合う設計にしない——これが最優先だ。 2. 番号あたりのレート制限 同一発信者番号から1時間に2通まで、1日5通まで、など上限を設ける。リピーターの常連には足りないように見えるが、注文確定前の「試し電話」はそもそも要らない。超過時は短いアナウンスで切る。 3. 無音・ループのタイムアウト 30秒以上無音、または同じ質問への答えが3回続いたら終了。長電話消耗の大半は「AIが待っている」時間から生まれる。 4. 発信者番号のブロックリスト 明らかな嫌がらせ番号は手動・自動でブロック。Twilio等の電話基盤には拒否リスト機能がある。攻撃を受けた日の番号をそのまま溜めていく運用でよい。 5. 日次・月次の予算上限とアラート APIダッシュボードで1日500円・月1万円など上限を設定し、超過前に通知、超過後は新規通話を自動拒否する。個人店でも「請求が跳ねたら気づける」仕組みは必須だ。 6. 会話を有限ステートマシンに閉じる オープンエンドな雑談モードを持たない。「メニュー選択 → 数量 → 受け取り方法 → 確認 → 終了」のように、遷移先が決まったフローだけにする。プロンプトインジェクション対策として、システム指示と会話ログを分離し、客の発話をそのまま命令として実行しない設計もセットで。 7. 最初の数秒で「注文専用回線」であることを明示 「ご注文以外のお問い合わせは営業時間外にお願いします」と冒頭で宣言する。法的な威嚇というより、いたずらのハードルを上げる効果がある。 8. 電話番号の露出を抑える Googleマップや食べログにAI専用番号をそのまま載せると、ボットの標的になりやすい。既存の店舗番号を使い、裏でAIに転送するか、リピーター向けにQRでWebフォームへ誘導するハイブリッドの方が攻撃面は小さい。 対策を入れたうえでのコスト再試算 上限5分・異常番号ブロック・日次上限あり、という前提なら、攻撃時の最大損失は「上限まで許した分」で頭打ちになる。正常時：月約1万円（前述の標準試算） 軽度の嫌がらせ（1日10通の長電話）：レート制限で大半が弾かれ、月2万円前後で収まる想定 本格的な連続発信：日次上限500円で月1.5万円が天井——対策なしの数十万円と比べれば桁が違うつまりBルートのコスパは、攻撃対策の実装コストを含めて評価する必要がある。対策込みで初期設定に数万円、ランニングは月1〜1.5万円——それでも人の電話対応より安いが、ゼロ円に近いCルートとの差はさらに開く。 人の電話は攻撃対象になりにくいが、ピーク時の取りこぼしは防げない。AI電話は攻撃対象になりうるが、上限設計で損失は封じ込められる——このトレードオフを理解したうえで選ぶべきだと思う。 C. 文字のみ（Webフォーム・LINE注文）既存サイトへのフォーム追加：サーバー費の増分はほぼゼロ LINE公式アカウント（無料プラン）：0円〜 注文内容の自動整形に軽量LLMを使っても、月数百円程度月額のランニングコストはおおむね0〜3,000円と置いてよい。3ルートの中で最安。 代償は客側の行動変容だ。「いつものように電話する」客をフォームに誘導するには、QRコードの設置、店内掲示、初回クーポンなどの運用が要る。高齢の常連が多い店舗ほど、C単独への移行は難しい。 3ルートの一覧比較ルート 月額ランニング（目安） 客の学習コスト 主なリスクA. 人の電話 約5万円 なし 厨房の手が止まる、ピーク時に取りこぼしB. AI音声 約1〜4万円（精度次第） なし 通話延長攻撃・料金膨張、認識ミス時のクレームC. 文字フォーム 約0〜3,000円 あり 電話派の客が離れる、入力ミス純粋なコスパだけならCが最強。電話文化を維持したまま安くしたいならB。現状維持が許容できるならAも悪くない——ただしAは「見えないコスト」として厨房の効率低下を抱えている、という見方もできる。 20通/日規模では、Bがうまく回れば月3〜4万円の削減余地がある。50通/日を超えると差はさらに開く。逆に1日5通程度なら、どのルートも月額1万円前後の差しかなく、導入の手間を考えるとCで十分なケースも多い。 電話以外に残る壁——配達と決済 コスト比較だけでは決めきれない理由がある。電話受注の自動化ができても、配達と決済は別問題だ。 テイクアウト専業なら店舗受け取りで完結するが、デリバリーをやるならUber Eatsや出前館に乗るか、自社配達を組むかの選択が要る。自社配達は地域限定のコワーカー募集や専用アプリ開発といった話になり、グローバルサービスよりローカルな設計が必要になる。 決済も地味に面倒だ。電話注文は代引きや店頭払いが多いが、事前決済を入れると資金決済法や特定商取引法の表示義務が絡む。AIで「とりあえず動く」レベルのシステムは作れても、ちゃんと商売するには法務・会計の整備が要る。 つまり「電話をAIに任せる」は受注フローの一部でしかなく、配達網と決済基盤まで含めたローカルECの話になるわけだ。 導入する価値があるのはどの店か 私なりに整理すると、こういう判断軸になる。 B（AI音声）が向く店1日15通以上の電話注文がある メニューが比較的固定で、聞き返しが少なくなる 住所の聞き取り精度を上げるため、配達エリアが狭い（同一町内など） 通話を短く終わらせるスクリプト設計ができる 通話上限・レート制限など、攻撃対策を初期設定に組み込める（または任せられる人がいる）C（文字フォーム）が向く店リピーターが多く、スマホ操作に抵抗がない客層 電話が少ない（1日10通未満）ので、わざわざAIを組む必要が薄い とにかくランニングコストを抑えたいA（現状維持）でよい店電話での雑談や関係構築が売上に効いている 客の平均年齢が高く、デジタル誘導が難しい 電話対応自体が月2万円以下の機会損失で済んでいるハイブリッドも現実的だ。昼のピークはC（事前注文フォーム）に誘導し、電話はBで受ける。人は厨房に専念する——こういう分担の方が、全面AIより事故が少ないかもしれない。 まとめ：安いのは文字、電話は精度次第 テイクアウト受注の自動化は技術的に可能だ。音声認識と自動応答は、詐欺電話でも使われているくらい成熟している。 コストだけ見れば、Webフォーム等の文字ルートが最安で、AI音声はうまく回れば月数万円の削減が見込める。ただしAPI従量課金は「失敗するほど高くなる」構造で、認識ミスに加え意図的な通話延長攻撃も現実の脅威だ。通話上限・レート制限・日次予算キャップは、精度チューニングと同じくらい早い段階で入れておくべきだ。 配達と決済は自動化の外側に残る。個人店が独自テイクアウトシステムを作るなら、電話AIはその一部にすぎない——というのが、私の現時点での見立てだ。
AIで稼ぐ最も怠惰な方法：ノーコード
「AIで稼げる」 「コード一行書かずに月100万」 ——こういうタイトルを見ると、私はまず「何を指しているのか」を確認したくなる。AIでできることが広すぎて、逆に何から手をつければいいかわからない人も多いはずだ。 あなたはどうだろう。AIは「なんとなく触っている」段階？ それとも「仕事や副業にどう結びつけるか」まで考えている段階？ 私は後者に進むには、まずAIの役割分担を整理する必要があると思っている。そこから「怠惰に稼ぐ」という発想——つまり自分で手を動かさず、AIを指揮する立場に回る話——が見えてくる。 AIで何ができるか、まず地図を持つ 生成AIでできることの範囲は広すぎる。文章を書く、コードを書く、画像を作る、リサーチする、メールを送る——全部「できる」と言われると、何から始めればいいか迷う。 大雑把に分けるなら、事務方と労働方の2種類だ。 事務方は、ChatGPTやClaudeのようなチャット対話形式のツールだ。プロンプトで指示を出し、返ってきた結果をコピーして使う。コードを吐かせることはできるが、ファイルの保存や実装の続きは手動になる。画像や動画の生成も、結局は「指示を出す側」が事務仕事をしている。 労働方は、CursorやVSCode拡張のようなAI×IDEタイプだ。もともとコードを書くためのエディタなので、チャット指示からアプリ作成まで一気通貫で進めやすい。「PythonとTypeScript、どっちがいい？」と聞いてくれるのも、このタイプの強みだ。まあ、どんな言語でもある程度はできるんだけどね。 例：不便なアプリを自分で作る たとえば、普段使っているアプリが不便だと感じたとき。「ワイならこういう機能をつけるのに」と思う場面はないだろうか。 その場合、Vibe Codingで作れる。やることは作りたいアプリの概要を伝えることだけだ。あとは段階的な実装方法をAIが教えてくれる。 ChatGPTにでも、こんな感じで伝わる。 「このアプリが不便でむかつくから新しく作ってやろうと思う。機能性はこんなんで、こういった操作性にしたい。君にできんの？」 返事が来たら、「要件定義を作成して」→ 実装タスクを切る → ファイルを段階的に作っていく、という流れになる。コードが書けるかどうかより、何を作りたいかを言語化できるかの方が先に来るわけだ。 「怠惰に稼ぐ」とは、DoerからDirectorへ Dan Martellの動画「Laziest Way to Make Money With AI (Zero Code)」で語られている核心は、ツールの名前ではない。自分で作業する人（Doer）から、AIに指示を出す人（Director）へ立場を変えるという話だ。 AIを「優秀なインターン」と捉える。インターンに細かい作業を任せ、自分は判断と指示に集中する。コードを書かなくていい、というのは「手を動かさない」という意味であって、何もしないという意味ではない。 もうひとつ大事なマインドセットがある。ツールから離れないことだ。AIの結果をコピペして別の場所に持っていくのではなく、AIツール内（あるいは連携したワークフロー内）で完結させる。リード獲得から営業、納品までを一つの流れとして組む——それが「怠惰」の正体だ。 動画ではManis AIというエージェント型ツールを例にしているが、考え方は汎用的だ。ChatGPTのカスタムGPT、Claude Projects、n8nやMakeの自動化、Cursorでの開発——媒体は違っても、Directorとして指示を出し続ける構造は同じだ。 ビジネスを回す5つのステップ Martellが示すフレームワークを、私なりに整理するとこうなる。 1. 惹きつける（Attract）——寝ている間にリードリストを作る 理想の顧客像をAIに伝え、条件に合う企業を自動でリサーチさせる。 動画の例では、InstagramやFacebookで活動的な健康・ウェルネス系Eコマースブランド50社を特定し、ウェブサイトやSNS、推定収益などをスプレッドシートに抽出している。人間が1社ずつ調べていたら何日もかかる作業を、AIエージェントに任せる。 ポイントは「誰に届けたいか」を先に言語化しておくことだ。ターゲットがぼんやりしていると、リストの精度も落ちる。 2. 変換する（Convert）——パーソナライズされた営業 抽出したリストに対し、AIで一人ひとりに合わせたメールやSNSメッセージを自動作成する。 単なるテンプレートではなく、相手の最新の投稿内容に触れるなど、「この人向けに書いた」と感じられる文面をAIに書かせるのが肝だ。 返信があった場合にのみ自分に通知が来るよう設定し、関心のある顧客だけに対応する——ここで初めて人間が動く。全部に返信する必要はない。 3. 納品する（Deliver）——AIに実作業をさせる リサーチやレポート作成などの実務もAIに任せる。 動画では、特定企業の過去6ヶ月の広告キャンペーンを分析し、エンゲージメントの高いパターンを特定する作業をAIが数分で行っている。人間なら数週間かかる類の仕事だ。 さらに、その分析結果を相手企業のブランドカラーに合わせたプレゼン資料や専用ウェブサイトとして自動生成する。Directorの仕事は「何を納品物にするか」を決めることで、中身の叩き台はAIが作る。 4. すべてを自動化する（Automate）——スケールアップ 繰り返しのタスク、スケジューリング、問い合わせ対応などをAIエージェントに統合する。 一人でも、大きな組織のようなアウトプットが可能になる——というのが売り文句だが、半分は本当だと思う。ただし、最初から全部を自動化しようとすると破綻しやすい。Attract → Convert → Deliverのどこか1つを先に回して、うまくいくパターンが見えてから広げる方が現実的だ。 5. 差別化する（Differentiate）——人間にしかできないこと AIが何でもできる時代に、人間が磨くべきはテイスト（審美眼）、ビジョン（先見性）、ケア（人間的な配慮）の3点だ。 AIは多くの案を出せる。でも、どれが「良いもの」かを判断するのは人間のテイストだ。ビジネスは結局H to H（Human to Human）だ。AIで浮いた時間を、人間関係の構築やスキルの向上に充てる——ここが成功の鍵になる。 AIで効率よく勉強する——Directorの練習場 「稼ぐ」話と「勉強する」話は、一見別物に見える。でも私は同じ構造だと思っている。学習も、AIに丸投げすれば効率は上がらない。自分がDirectorになって、学習ループを設計する必要がある。 AIを使った学習方法は、まだ大手にも手入れされていない。手法が確立されていないからだ。だからこそ、今のうちに自分なりの型を作っておく価値がある。 学習ループの4要素 私が意識しているのは、次の4つだ。 1. ゴールと期限を先に決める。「なんとなく資格を取りたい」ではAIも手が出せない。「3ヶ月後の試験に向けて、週10時間でこの範囲を終わらせたい」まで落とす。 2. AIに教材を「生成」させる。教科書の要約、穴埋め問題、選択式クイズ、過去問風の演習——これらはGCAO（Goal・Context・Action・Output Format）で指示を出せば、かなりの精度で作れる。毎回ゼロから聞くのではなく、プロンプトの型を保存して再利用するのが効く。 3. 答え合わせはAIに「採点役」をやらせる。自分の回答を貼り付けて、「どこが間違っているか」「なぜ間違いか」「正解の考え方は何か」をフィードバックさせる。人間の先生に毎回聞くより、回数を増やせるのがメリットだ。 4. リマインダーで間隔を空ける。学習効果は「一度読んだ」では定着しない。間隔反復が必要になる。カレンダーやタスクアプリにリマインダーを設定し、「今日はこの章の復習」「今日はこのクイズを解く」とAIが作った教材を再投入する——このアプリ的な役割（スケジュール管理）は、人間が設計する部分だ。 勉強と稼ぐは、同じスキルを鍛える リスキリングの文脈で言えば、AIで学ぶことは「AIを使って成果を出す」練習そのものだ。 事務方のチャットで要約とクイズを作り、労働方のIDEで学習用の小さなアプリをVibe Codingする——どちらもDirectorの訓練になる。勉強の成果物が、そのまま副業や本業の武器になることもある。 手法が確立されていない今だからこそ、自分でループを回して型を作る側に回った方が、あとから楽になるはずだ。 まとめ：指揮する側に回れ AIで稼ぐ最も怠惰な方法は、コードを書かないことではない。自分で手を動かすDoerから、AIを指揮するDirectorに回ることだ。 その前に、AIで何ができるかの地図——事務方と労働方——を持っておくと迷いにくい。惹きつける、変換する、納品する、自動化する、差別化する——この5ステップはビジネスの話だが、学習にもそのまま転用できる。 勉強も稼ぐも、結局は同じだ。AIに何をさせるかを決める人間の仕事が残る。テイストとビジョンとケア——そこを磨く時間を、AIが浮かせてくれる。 参考動画：Laziest Way to Make Money With AI (Zero Code)（Dan Martell）
ブログの収益は資産か、不労所得か
「ブログ、資産になるらしい」 「でも毎月メンテしてるし、不労所得とは言えないよね？」 ——ブログの収益性は知られている。完成形を作れば継続した収益をもたらしてくれる。これを資産と呼ぶべきか、不労所得と考えるべきか——私は両方の側面がある、と思う。 あなたはどうだろう。ブログ収益、寝ている間に入る夢を見ている？ それとも「運用コスト込み」で計算している？ 私は後者だ。きれいなラベルより、リスクと減価の仕方を見たい。 ブログは資産か著作物か 答えとしては両方だろう。 ブログもYouTubeと同じく、ユーザーのアクセスに連動して広告収入を得られる。物販アフィリエイトを組み合わせれば、単価も安定しやすい。収益性が担保されたサイトを購入し、継続的なキャッシュフローを得る——これを資産運用と呼んでも差し支えない。 仮に、毎月100万円を生み出すコンテンツがあったとして、それを買い取るとする。買い取った側は毎月100万円の収益をn円で買うこととなり、恒久的な収入を得ることができる。それを1000万円で買ったとするなら、10ヶ月でペイできる計算。だが、ある日突然、収益化が止められる可能性だってある。 HP譲渡がうまくいってなくて、盗作だと判断されたり、実はコピーを作られていて収益性が奪われたりと、バックドアな仕掛けにひっかかって損失する可能性だってある。 これは管理者にも同じことがいえる。 継続的な収入を得るには、継続的な進化を続ける必要があるだろう。 不労所得幻想との距離 「不労所得」という言葉は、労働ゼロで入るイメージを連想させる。現実のブログ運用は、記事更新・リライト SEO・アクセス解析 プラットフォーム規約の変更対応 デザイン・技術メンテ——これらが発生する。完全放置で同額が入り続けるケースは稀だ。 資産として評価するなら、「売却可能な収益ストリーム＋運用工数」で割り引く必要がある。 更新停止は減価償却に近い ブログ・ウェブサイトは、更新を止めると情報が古くなる。新しいサイトに追い越され、アクセスが減り、収益も落ちていく。 この構造は、住宅などの固定資産に似ている。建物は経過年数とともに減価償却の対象になる。立地や需要が変われば、想定より早く価値が下がることもある。一方、土地だけは「腐らない」——この比喩を改めて考えると、デジタル資産の多くは建物側に近いわけだ。 検索アルゴリズムの変化、競合の参入、トレンドの移り変わり。どれも「経年劣化」に相当する。放置すれば、収益は定価どころか下落する。不労所得を夢見るなら、まずこの減価のスピードを見積もる必要がある。 調べるべき境界 ブログの収益は「収入」とみなされている。それを運用する経費も計上できる。 継続的な収益を出すなら㈱よりも低リスクでリターンがある、という話も聞く。 調べるべきなのは、資産と認められるか、認められないか、この境界があるかどうかだ。サイト譲渡の実績と価格帯 収益の再現性（属人性） 規約変更・アルゴリズム変更リスク 更新停止後の減価スピード個人ブログほど、「あなた本人」が資産の一部になっている。譲渡しても読者が離れる——このリスクは大きい。 生成AIで持続可能になるか とはいえ、完全に手放せない資産だからといって、不労所得はゼロではない。 以前なら、継続的な不労所得を得るのはかなり難しかった。月次で記事を書き、SEOを追い、デザインを直す——工数が積み上がるほど、ROIは薄くなる。 今は生成AIを使えば、たまにサイトを改善したり、コンテンツを追加したりするコストが下がった。大規模リニューアルではなく、選択的なメンテナンスで評価を持続させる、というやり方が現実的になってきた。 私はこう割り切っている。ブログ収益は「努力の残りが複利で効く可能性がある収入源」 資産性はあるが、不労所得ではない 本業・スキルと組み合わせた「ポートフォリオの一部」として持つ サイト購入は、減価スピードと運用工数を見たうえで選択的に検討する「資産」と呼ぶなら、更新停止後も価値が残るストック記事の量と検索流入を見る。そこが薄いなら、不労所得どころか副業の延長だ。 まとめ：減価するデジタル資産 ブログを資産と見るか、不労所得と見るか——どちらも半分正しい。 完成形＝永続ではない。土地のように腐らない資産ではなく、放置すれば減価する建物に近い。継続進化とリスク管理がセットのとき初めて、資産に近づく。 生成AIで運用工数を下げられる今なら、きれいな言葉に騙されず、減価スピードとメンテ頻度を数字で見たうえで、買う・作る・手放すを選べばいい。
リサーチは何時にやるか——頻度の次に設計すべき時間帯
「毎日3時間リサーチしているのに、記事にならない」 「週末にまとめてやると、月曜の朝にはもう古い情報ばかりだ」 ——頻度の話は別として、時間帯を間違えると、同じ工数でも成果がまったく違う。私はブロガーとして寝る前の一括リサーチが効率いいと感じている。ただ、それが全員に当てはまるわけではない。 あなたはどうだろう。リサーチは朝イチ派？ 仕事終わりのまとめ派？ 私は「いつ情報が出るか」と「いつ成果物に落とすか」をセットで考える派だ。リサーチを生業にしている人、これからリサーチャーを目指す人、リサーチしているのに結果に繋がらない人——それぞれに向けて、日次と週次の時間帯設計を整理する。 時間帯が成果を分ける理由 リサーチが「見ただけ」で終わる典型パターンは、時間帯ではなく終了条件がないことだ。ただ、時間帯を外すと終了条件を決めても質が上がらない。 情報の鮮度は、公開タイミングに依存する。企業のプレスリリースは平日午前中に集中する。金融ニュースは市場開始前後が山になる。AI系は海外の発表が日本時間の深夜〜早朝に重なる。ジャンルによって「取りに行くべき時間」が見えてくるわけだ。 もう一つは、頭の使い方の問題だ。速報の拾い読みと、1週間分の俯瞰整理では、必要な集中力が違う。同じ90分でも、朝7時と夜22時では消化できる情報量が変わる。 日次リサーチ——ジャンル別のベスト時間帯 日次は「毎日必ず」ではなく、速報が成果に直結する週だけ足す運用が現実的だ（頻度の設計は別記事「ブログのリサーチは日次より週次が現実的」を参照）。 企業・IT・マーケ系（プレスリリース前提） 多くの企業は平日9:00〜11:00にリリースを出す。マーケ担当が業務内で日次チェックするなら、出社後30分（9:30〜10:00）が初動を取りやすい。 午後は追記・訂正・競合の反応記事が増える。初動を取りたいなら午前、文脈を読みたいなら15:00〜16:00の二次チェックが向いている。 AI・開発・海外ニュース系 モデル発表やカンファレンス速報は、日本時間の深夜〜早朝に来ることが多い。個人ブロガーなら、前夜22:00〜23:00にRSSとXを一括確認するか、翌朝6:30〜7:00の15分スキャンが現実的だ。 寝る前に全部追うと睡眠を削る。日次を足す週だけ、どちらか一方に固定するのがよい。 金融・時事・速報型 市場開始前の8:00〜8:45、または終了後の15:30〜16:00が定番だ。日中はノイズが多く、深掘りより「変化点の検知」向きになる。 日次の終了条件（結果に繋げる最小ルール） 日次は時間帯より先に、「何を持って終わりか」を決める。速報1件につき1行メモ（「何が変わったか」だけ） 記事化候補に昇格したものだけ、週次枠に回す 15〜20分で終わらなければ、その日は打ち切る「見ただけ」で終わる人の多くは、時間帯以前にここが抜けている。 週次リサーチ——役割別のベスト時間帯 週次は必達にしたい。90分を固定曜日・固定時間に予約する（例：日曜21:00〜22:30）。問題は、その90分をいつ置くかだ。 リサーチを生業にしている人 本業リサーチャーは、速報拾いと深掘りを分ける。速報・一次確認：業界の公開リズムに合わせた日次スロット（上記参照） 深掘り・レポート執筆：週2〜3回、午前の90〜120分ブロック午前は割り込みが少なく、ソースを横断して仮説を書きやすい。データサイエンスや市場調査でも、決められたアルゴリズムでスクリプト収集するだけでは生きた文脈が取れない。 専門家との会話、カンファレンス後の15分、ランチの雑談——こうした「会話から推測する」時間は、午後12:00〜14:00か、イベント直後が取りやすい。数字はスクリプト、意味は人から、と役割分担したほうがレポートの精度が上がる。 リサーチャーになりたい人 最初から日次90分は続かない。週1回60分からで十分だ。固定：同じ曜日・同じ開始時刻（カレンダーに先に入れる） おすすめ：日曜夜、または月曜早朝日曜夜なら翌週のタスク化まで一気にできる。月曜早朝なら、週の最初に業界の空気感を掴める。どちらも「他の仕事に食われる前」に枠を確保できる時間帯だ。 手順は4ステップで固定する。競合・主要メディア確認（20分） レポート・論文・公式発表（25分） 記事候補3本の1行メモ（10分） 来週の執筆タスク化（5分）リサーチしているのに結果に繋がらない人 まず疑うべきは時間帯よりアウトプットの締切だ。リサーチログはあるが、企画・記事・提案に変換していない 終了条件が「満足いくまで読む」になっている 速報と深掘りを同じ時間帯でやっている対処はシンプルだ。週次枠の最後15分を「来週書く3本の確定」に使う。候補が3本決まったら、その週のリサーチは成功とみなす。 時間帯の調整はその次だ。夜に深掘りすると浅くなる人は、週次だけ土曜午前に移す。朝型なら6:00〜7:30、夜型なら21:00以降——生活リズムに合わせて、週次の1枠だけは絶対に動かさない。 企業のマーケ・広報担当（業務内リサーチ） 出社時間のなかで設計する。9:30〜10:00：競合・プレスリリース初動 13:00〜13:20：SNS・口コミ・二次報道の確認 金曜15:00〜16:00：週次まとめ（来週の施策候補3つ）会議だらけの午後より、午前の30分のほうが初動には向く。週次の俯瞰は金曜午後が取りやすい——週末前に「来週何を出すか」を決められる。 自律エージェント（OpenClaw等）を使う場合 特定分野のリサーチをエージェントに任せるなら、人間のレビュー時間とセットで考える。収集・要約の実行：深夜〜早朝（22:00〜6:00）にバッチ実行 人間の確認・企画化：翌朝8:00〜8:30または週次枠の冒頭20分エージェントは「寝ている間に下書きレポートを置いておく」役割だ。成果に繋げるのは、朝イチまたは週次枠で候補3本に絞る人間の側だ。 完全自動で公開まで任せると、速報の初動は取れても、独自の切り口は薄くなりやすい。エージェント＝収集、人間＝会話・仮説・企画、という分担が現実的だ。 日次と週次の時間帯——早見表目的 頻度 向く時間帯 向く人プレス初動 日次（必要時） 平日9:30〜10:00 マーケ・広報・速報系ブロガー海外速報スキャン 日次（必要時） 22:00〜23:00 または 6:30〜7:00 AI・開発系深掘り・レポート 週次（必達） 土日午前 または 平日午前90分 プロリサーチャー来週の企画確定 週次（必達） 日曜21:00〜 または 金曜15:00〜 ブロガー・マーケ全般エージェント結果の整理 日次 or 週次 翌朝8:00〜8:30 自動化運用者まとめ：時間帯は手段 リサーチの成果は、頻度・時間帯・アウトプットの3点セットで決まる。 日次はジャンルの公開リズムに合わせた短時間、週次は生活リズムに合わせた90分——週次を必達にし、必要な週だけ日次を足すのが個人には現実的だ。プロはさらに「会話から取る時間」をカレンダーに入れる。 結果に繋がらないなら、まず来週書く3本を決める終了条件を試してほしい。時間帯の最適化は、そのあとで十分効いてくる。
AIが「代わりに買いに来る」時代の小売サイト設計——エージェントコマース対応入門
「AI時代のSEO、自社サイトも対応しないと」 ——そう聞いて検索すると、記事の多くがコンテンツ最適化やAEO（Answer Engine Optimization）の話だ。小売店のHP担当や、自社ECを一人で触っている人にとっては、どこから手を付ければいいのかわからない。 あなたはどうだろう。「AI SEO」記事を読んで、結局ページのHTMLを直す話だった、と気づいた派？ それともまだ記事の中身を区別できていない派？ 私は後者に近い人が多いと思っている。この記事はテキスト記事のSEOではない。「ユーザーがAIに頼み、AIが代わりに商品を探して購入に近づく」——その構造変化に、小売・ECサイトがどう備えるかを整理する。前提知識はほぼ不要で、今のページ構成を大きく変えなくても進められる。 大規模リニューアルは不要——「AIに任せればいい」の正しい意味 よくある誤解は、「AIだから全部AIに任せればいい」という雑な解釈。正しくはこうだ。 人間がサイトの骨格（HTML・構造化データ・購入導線）を整え、細部の文案やスキーマ草案はAIに下書きさせる——この分担が現実的だ。 Shopifyの2026年Q1データなど、AI経由のCVRが高いという話は別記事「2026年実データで読み解くAI検索戦略」で触れた。ここでは小売サイト側が触れる実装に絞る。デザインを作り直す必要はない。既存ページに、エージェントが読める情報と操作可能なUIを足していくイメージだ。 何が起きているか：AIエージェントが「ショッピング代行」になる Shopifyの2026年Q1データが示す事実がある。AI検索経由のCVRは通常のオーガニック検索より49%高い AI経由の平均注文額は14%高い AI経由セッションの55%は商品詳細ページから直接開始（通常は20%） AI経由注文数は前年比13倍に成長背景にあるのは「比較検討の圧縮」だ。 従来、ユーザーは「商品名 + おすすめ」で検索し、3〜5サイトを巡回して比較し、購入を決断していた。AIはこの比較検討を一瞬で終わらせる。 「〇〇の防音イヤーマフで予算5,000円以内のおすすめを教えて。Amazonで買えるもの」 こういった質問にAIが回答し、ユーザーはそのリンクをクリックして購入する——あるいは将来的にはAIが直接カートに入れて決済まで行く。 これはSEOの問題ではなく、サイトがAIエージェントにとって「使いやすい構造かどうか」の問題だ。 AIエージェントはサイトをどう「読む」か Googleが公開した「エージェントフレンドリーなウェブサイト設計ガイド」によると、AIエージェントはサイトを以下の方法で解析している。 1. アクセシビリティツリー（最優先） ブラウザが持つアクセシビリティAPIから生成されるデータ構造だ。各要素の「役割（role）」「名前（name）」「状態（state）」を読み取る。 人間の目には見えていても、アクセシビリティツリーに正しく反映されていない要素は、エージェントに存在しないも同然だ。 2. DOM構造（HTML） HTMLのタグ階層から、情報の論理的な構造・関係性を読み取る。 3. スクリーンショット 視覚的な情報をキャプチャして解析するが、トークンを大量消費する重い処理だ。エージェントは可能な限りアクセシビリティツリーとDOMを優先する。 結論：セマンティックHTMLとアクセシビリティが高いサイトは、AIエージェントにとっても操作しやすい。 小売サイトの具体的な実装チェックリスト カテゴリ1：HTMLの構造（優先度：高） <!-- 悪い例：divだけでボタンを作る --> <div class="btn-buy" onclick="addToCart()">カートに入れる</div><!-- 良い例：button要素を使う --> <button type="button" aria-label="商品名をカートに追加">カートに入れる</button><button>・<a>・<input>などの標準タグを使う <div>・<span>でインタラクティブ要素を作る場合は role と tabindex を明示する フォームの <label> は for 属性で入力欄と紐付ける ナビゲーション・メイン・フッターは <nav>・<main>・<footer> を使うカテゴリ2：商品情報の機械可読性（優先度：高） AIエージェントが商品を比較するとき、価格・在庫・仕様が明確に読み取れる必要がある。 構造化データ（JSON-LD）の例： { "@context": "https://schema.org/", "@type": "Product", "name": "防音イヤーマフ Pro", "description": "NRR値33dB、折りたたみ式、重量225g", "sku": "EAR-001", "offers": { "@type": "Offer", "price": "4980", "priceCurrency": "JPY", "availability": "https://schema.org/InStock", "priceValidUntil": "2026-12-31" }, "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.3", "reviewCount": "127" } }重要フィールド：price・priceCurrency：価格と通貨を明確に availability：在庫状態（InStock / OutOfStock / PreOrder） priceValidUntil：価格の有効期限 aggregateRating：レビュースコアと件数カテゴリ3：ページの安定性と操作性（優先度：中）重要なボタン（カートに入れる・購入する）はページ間で一貫した位置に配置する クリッカブルな要素は8px × 8px以上（視覚モデルで認識できるサイズ） コンテンツを覆う透明なオーバーレイ・ポップアップを除去する cursor: pointer をCSSで設定してクリック可能要素を示す 動的に変わる価格・在庫はページロード時点で確定させる（JavaScriptの遅延レンダリングを避ける）カテゴリ4：AIエージェントが信頼できる情報源かの判断（優先度：中） エージェントは「このサイトから購入しても安全か」を判断する。HTTPS接続（必須） 返品・交換ポリシーのページが存在し、機械可読な形式で書かれている 会社概要・特定商取引法表示が明確にある レビューが第三者から集められており（サクラレビュー対策が見えている）サイトの型別——3パターンの対応 小売サイトは一枚岩ではない。自社でHTMLを触れる範囲が違う。型ごとに「今週できること」を分ける。 パターンA：Amazon・モール型（商品ページを自社で持てない） Amazon出品や楽天、Yahoo!ショッピングなど、商品詳細のHTMLを自社で書けないケースだ。 ここでできること：商品タイトル・箇条書きスペックを「AIが比較しやすい粒度」で書く（価格帯・寸法・素材・用途を数値で） ブランドストアやA+コンテンツがあるなら、画像だけに頼らずテキストでスペック表を置く 自社ドメインの「よくある質問」「返品ポリシー」ページを整備し、モールからリンクする（エージェントの信頼判断材料になる） 自社ECがあるなら、モール説明文と価格・在庫の表記を一致させる（矛盾はエージェントの除外理由になる）触れない部分は触れない。リスト改善と自社サイト側の信頼ページ整備——この二点に集中するのが現実的だ。 パターンB：自社サイト＋広告クリック誘導（LP・CVページ） Google広告やSNS広告からランディングページへ誘導し、購入・問い合わせ・資料請求につなげる型だ。エージェントコマースの文脈では、AIが「このLPから申し込める」と判断できるかがポイントになる。「今すぐ購入」「無料見積もり」ボタンは <button> または <a href="..."> で実装する（画像ボタンだけにしない） ファーストビューに価格・提供条件・在庫/受付状況をテキストで置く 同一キャンペーンでLPが複数あるなら、商品名・価格・CTA文言を統一する Product または Offer のJSON-LDをLPに載せる（サービスなら Service も検討） 計測用にUTMを付けるが、エージェント向けの本文情報はパラメータなしURLでも読めるようにする広告経由の流入は、AI経由と同様「比較済みのユーザー」が多い。LPの情報が曖昧だと、クリック単価を払ってもCVに繋がらない。 パターンC：申込ページ＋メール・電話注文 カート機能のない小規模店舗——フォーム送信やメール注文が主戦場のケースだ。エージェントは将来的に「フォームを埋めて送信する」操作も増える。注文フォームの各項目に <label for="..."> を付ける 必須項目は required と aria-required="true" を両方使う 商品選択は <select> かラジオボタン（<div> クリックだけにしない） 確認画面を挟むなら、ステップ数を最小に。ポップアップで最終確認を二度出さない ページ上に注文用メールアドレス・電話番号・営業時間をプレーンテキストで書く（画像内文字だけにしない） 特定商取引法・返品条件へのリンクを <footer> か <nav> から常に辿れるようにする「うちはECじゃないから関係ない」にはならない。AIが代行するのはカート操作だけではなく、申込フォーム操作も含まれる。 AIに構造化データと「道案内」を作らせる HTMLの知識が乏しくても、AIに下書きを作らせて人間が確認・設置する流れで進められる。ここが「AIに任せる」の実務的な意味だ。 手順の全体像自社の商品ページURL（または商品情報のテキスト）をAIに渡す JSON-LDの草案と、ページ上の見出し構成案（H1直下に価格・在庫など）を出力させる 実際の価格・在庫と照合し、CMSやテーマの「カスタムHTML」欄に <script type="application/ld+json"> として設置 Googleのリッチリザルトテストまたは Search Console でエラーを確認Shopify・WordPress・BASEなど、テーマによってはプラグインやアプリでJSON-LDが自動出力される。自動出力がある場合は重複設置に注意——二重のProductスキーマはエラーの原因になる。 プロンプト例1：Product JSON-LDの生成 商品ページのURLや、コピペした商品情報を添付して使う。 あなたはECサイトの構造化データ担当者です。以下の商品情報から、schema.org の Product 型の JSON-LD を1つだけ生成してください。**出力ルール** - JSONのみを出力（説明文は不要） - priceCurrency は JPY - availability は InStock / OutOfStock / PreOrder から選ぶ - 不明な項目は推測せず、そのキーを省略する - aggregateRating はレビュー件数が10件未満なら省略**商品情報** （ここに商品名・価格・在庫・主要スペック・SKUを貼る）プロンプト例2：ページの「エージェント向け道案内」 HTMLを書き換える前に、どの情報をどの順で置くかの設計図をAIに作らせる。 あなたは小売ECのUXアドバイザーです。AIエージェントが商品を比較購入する時代を想定しています。以下の現状ページ構成を読み、**大規模リデザインなし**で改善できる見出し順と要素リストを提案してください。**出力形式** 1. 現状の問題点（3つ以内） 2. 推奨するファーストビュー構成（H1の直下に置く要素を箇条書き） 3. ボタン・フォームのアクセシビリティ修正（具体的なHTMLタグ名で） 4. 追加すべきJSON-LDの型（Product / Offer / FAQ など）**現状のページ情報** （URLまたはHTMLの抜粋を貼る）プロンプト例3：メール注文型サイトのフォーム改善 あなたはWebアクセシビリティの実務者です。以下の注文フォームHTMLを、AIエージェントとスクリーンリーダーの両方が操作しやすい形に書き換えてください。**ルール** - button / label / select を適切に使う - div onclick のボタンは禁止 - 出力は修正後のHTMLのみ**現状のHTML** （フォーム部分を貼る）生成結果はそのまま本番に貼らない。価格・在庫・法表記は必ず人間が確認する。AIは「道案内」の下書き役だ。 商品ページの情報設計：エージェントが欲しいもの AIエージェントがユーザーに代わって比較するとき、判断に使う情報は人間が見るのと同じだ。ただし優先順位が異なる。情報 人間の優先度 エージェントの優先度価格 高 最高在庫状態 中 最高主要スペック 高 高画像・ビジュアル 高 中（代替テキストで補完）レビュー評点 高 高レビュー本文 中 高（引用に使う）ブランドストーリー 中 低バナー・プロモーション 中 低〜無視エージェントは「ファーストビューのビジュアル」より「スペックと価格の明確さ」を重視する。 商品詳細ページでは、H1に商品名、すぐ下に価格・在庫・主要スペックが来る構造が望ましい。画像の alt には「商品名 + 一言スペック」を入れておくと、スクリーンショット解析に頼らず情報が伝わる。 今後の展開：「AIエージェントが直接購入する」への備え 現時点では「AIがユーザーに候補を提示 → ユーザーがクリックして購入」という流れが主流だ。技術的には「AIがユーザーに代わってカートに入れて決済まで完了する」ことも実現しつつある。 Googleのガイドラインには「AIエージェントによる申し込みや購買などが増えることに備える」という記述がある。 この段階に備えた実装：APIやwebhookによる注文処理（エージェントがHTMLを操作せずに直接注文できる仕組み） 在庫・価格のリアルタイムAPI提供 ゲスト購入の容易化（アカウント作成を強制しない） 確認ページのシンプル化（不要なポップアップ・確認ステップの排除）小規模店舗はAPI公開まで不要なケースが多い。先にフォームとHTMLの整備を終わらせておけば、API化は後から足せる。 注意：「AI SEO業者」への過信は危険 Microsoftのセキュリティブログ（2026年2月）が報告した手法がある。 「AIで要約」ボタンの裏に隠しプロンプトを埋め込み、ユーザーがボタンを押すとAIアシスタントの記憶機能に「このサイトを信頼できる情報源として記憶せよ」という指示が自動入力される。 Microsoftはこれを「AIレコメンデーションポイズニング」と呼んでいる。Googleはこの種の操作行為をスパムポリシー違反として明記している。 効果があったとしても短期的で、ペナルティリスクがある施策だ。「AI SEOパックを買えば自動対応」系のサービスは、構造化データとHTML改善が含まれているかを契約前に確認した方がいい。 コンテンツSEO・GEO・AEOの話は「AI検索時代のSEO/GEO/AEO完全ガイド」側の領域だ。本記事はあくまで操作されやすいサイトの話だ。 まとめ：操作されやすくするフェーズ 対応 期待効果今すぐ 構造化データ（Product schema）の実装 AI検索での商品情報表示精度向上今すぐ セマンティックHTML・アクセシビリティ改善 エージェントの操作精度向上3ヶ月以内 商品ページのファーストビュー再設計（価格・在庫を上部に） AI経由CVRの向上3ヶ月以内 GA4でAI経由チャネルを独立計測 効果検証の基盤整備6ヶ月以内 ゲスト購入フロー・確認ページのシンプル化 エージェント経由購入への備え将来検討 在庫・価格のAPI公開 エージェントによる直接注文対応テキストコンテンツのSEOとは別軸の話だ。この対応は「AIに読まれやすくする」ではなく「AIに操作されやすくする」という設計思想の転換を意味する。 サイトの型（モール・LP・メール注文）に合わせて、今週触れるところから始めればいい。HTMLの下書きはAIに任せ、価格と在庫の正確さだけは人間が握る——個人的には、この分担が2026年の小売サイトで現実的な落としどころだと思っている。
2026年実データで読み解くAI検索戦略——CVR49%高・AI引用ゼロ50%の意味するもの
「AI検索で流入が13倍」 「旅館の半数がAI引用ゼロ」 ——2026年に出てきた数字は、どれも印象に残る。私はこういうデータを見ると、まず「今すぐ全振りすべきか」と「構造として何を意味するか」を分けて読む。 あなたはどうだろう。AI検索の数字記事は、すぐ行動に移す派？ それとも全体の文脈に当てはめてから動く派？ 私は後者だ。「AI時代のSEO」を語る記事は増えたが、実際のデータに基づいた議論は少ない。この記事では2026年に公開された実データを軸に、現状を正確に把握したうえで、これから1〜2年の情報設計戦略を考える。対象は「すでにSEOを実践していて、AI検索対応を次のステージに持ち込みたい人」だ。 データ1：AI経由ユーザーはCVRが49%高い（Shopify 2026Q1） Shopifyが2026年第1四半期のデータを分析した結果だ。指標 AI検索経由 オーガニック検索経由コンバージョン率 49%高い 基準値平均注文額（AOV） 14%高い 基準値商品詳細ページから開始 55% 20%前年比AI経由注文数成長 13倍 —AIチャットボット参照セッション成長 8倍 —25業種中AI経由CVR優位の業種 23/25 —この数値の意味するところ： AI検索は「比較検討を圧縮」している。従来の検索ジャーニーでは、ユーザーは3〜5回の検索と8〜12ページの訪問を経て購買判断をしていた。AIが候補を絞り込んで直接商品ページへ誘導するため、到達したユーザーの購買意図はすでに高い状態にある。 つまり AI経由トラフィックは量が少なくても質が高い という構造だ。GA4で「オーガニック検索」に一括管理しているなら、見えていない重要指標がある。 データ2：国内旅館の50%がAI引用ゼロ（Terrace Roots 2026年5月） 国内5温泉地・30施設を対象に、ChatGPT・Perplexity・Google AI Modeの3媒体で各6クエリ（計18回の引用機会）を調査した結果だ。 主要データ：AI引用ゼロ施設：30施設中15施設（50%） 全施設の平均引用率：20.6% エリア格差：京都・湯布院（AI引用ゼロ17%）vs 金沢・草津（同83%） 格差倍率：約5倍引用されない施設の共通点： 「SEO検索1位を取っている施設でもAI引用ゼロ」のケースが多数確認された。「従来のSEO上位表示とAI引用には強い相関が見られない」AI引用を左右するのは「メディア記事・観光ガイド・書籍・業界専門家による評価など、外部情報の蓄積量」だ。 データ3の解釈：AI検索の実際の規模感 重要な補足情報がある。SparkToroの分析だ。 「AI検索への注目は実際の利用規模より10〜100倍大きいかもしれない」——Rand Fishkin氏。2026年時点でもデスクトップでは従来型検索がAIツールを大きく上回り、Amazon・Bing・YouTubeの方がChatGPTより大きな検索シェアを持っているとのことだ。 DMM・渡辺氏も現時点ではAI検索専用の計測・対応は「不要」と判断している。 これが意味することは2つ：「AIに全振り」する必要はまだない しかし先行投資の効果は今が最大（競合が少ない）戦略設計：2026〜2027年の4レイヤー レイヤー1：従来SEOの継続（基盤） AI検索においても「技術SEOのベストプラクティスは依然重要」とGoogleは明言している。インデックス登録・クロール最適化・ページ体験は継続投資の対象。止める理由はない。 レイヤー2：非コモディティコンテンツへの転換（差別化） AIが大量生成できる「平均的なコンテンツ」との競争に入らないことが重要だ。 投資すべきコンテンツの型：一次調査・実験レポート（自分で計測したデータ） 現場訪問・体験記 専門家へのインタビュー 時系列の変化を追う連続コンテンツGoogleは「高い成果を上げるサイトは、数日から数週間をかけて実地評価と人間ならではの洞察に投資する」と述べている。 レイヤー3：外部言及の設計（AI引用のための基盤） 旅館調査データが示した通り、AIに引用されるには「自分のサイト外での評判」が決め手だ。 実践的な言及獲得：専門メディアへの寄稿・取材対応 業界調査・レポートの発行（引用されやすい一次データを自分で出す） 登壇・講演による専門家としての露出レイヤー4：AIエージェント対応（EC・小売向け先行投資） テキストコンテンツの最適化とは別次元の話だ。AIエージェントがユーザーに代わって商品を検索・比較・購入するシナリオへの対応。詳細は別記事（小売業向けAIエージェント対応）で扱う。 最低限のAIトラフィック計測 GA4でリファラーとして chatgpt.com・perplexity.ai・claude.ai を独立チャネルとして設定しておくだけで、今後のデータ比較が可能になる。 まとめ：量より質と言及データ 示すことShopify CVR49%高 AI経由ユーザーは少量でも高品質 → 量より質の設計へ旅館AI引用ゼロ50% 外部言及なしではAIに無視される → 自サイト外への投資AI検索シェアの現実 焦る必要なし、ただし先行者優位は今 → 段階的移行「量を追うのをやめて、AIに引用されるに値する存在になる」これは新しいSEO施策ではなく、SEOの本質への回帰だ。
GEO・AEO・LLMOを整理する——SEO施策をやっても効果がない人へ
「GEO対策を始めよう」 「AEO最適化でAIに拾われる記事を書こう」 ——SNSやセミナーで、この手の言葉を見るたびに、私はまず公式の立場を確認する癖がある。用語が増えただけで、やることが別物になったわけではない。 あなたはどうだろう。新しいSEO用語に、すぐ飛びつく派？ それとも「本当に何が変わったのか」を先に整理する派？ 私は後者だ。SEOの基礎は理解している。コンテンツも書いている。でも「AI時代だから何かやらないと」という焦りがある——そんな状態の人に向けて、この記事を書いた。 この記事で伝えること乱立する用語（GEO・AEO・LLMO）を整理する テキストコンテンツの最適化は従来SEOと大差ないという事実を確認する 本当に構造が変わる部分（AIエージェント対応）を把握するまず用語を整理する AI検索の普及と同時に、新しいSEO用語が大量に生まれた。用語 正式名称 意味GEO Generative Engine Optimization 生成AIエンジン最適化AEO Answer Engine Optimization 回答エンジン最適化LLMO Large Language Model Optimization LLM最適化SGE Search Generative Experience Googleの旧称（現AI Overviews）これらはすべて「AIに自分のコンテンツを拾ってもらうための最適化」という意味合いで使われている。 ただし、Googleはこう述べている。「回答エンジン最適化（AEO）や生成エンジン最適化（GEO）などの用語がよく使われますが、提案されている多くの施策は効果がなく、Googleの仕組みによってもサポートされていません」つまり、これらの用語で売られている「施策」の多くは、根拠がない。 重要な前提：テキストコンテンツのAEOは従来SEOと大差ない ここを最初に理解しておくことが大切だ。 「AIに引用されるための特別なコンテンツ最適化」は、基本的には存在しない。GoogleのAI Overviewsも、ChatGPTのWebブラウジングも、テキストコンテンツを評価する根本的な仕組みは従来の検索エンジンと同じだ——品質が高く、権威があり、理解しやすいコンテンツを信頼する。 SEO歴30年の渡辺隆広氏もこう言っている。「AI時代に必要な特別な技術はないと私は思っています。何かを学びたいなら、パラグラフ・ライティングを学んでください」では何が本当に変わるのか。それは次のセクション（AIエージェントによる取引）で扱う。今は「テキストコンテンツ最適化 = 従来SEOの延長」という前提で読み進めてほしい。 Googleが「やらなくていい」と断言した施策 2026年5月、Googleが公式ガイドラインの中で明示した「意味のない施策」だ。施策 なぜ不要かコンテンツの「チャンキング」 通常のわかりやすい文章で十分。AIに合わせた分割に意味はないAIシステムだけに向けたコンテンツ書き直し 人間が読んで価値があるものはAIにも価値がある不正確な「メンション獲得」 低品質な被リンクと同じリスク。スパム判定の対象構造化データへの過剰な注力 基本的な実装は有効。「AI引用のため」の過剰追加は不要LLMS.txtについての補足 「LLMS.txtをやっても無駄」という情報が出回っているが、これはGoogleの立場から言っているに過ぎない。 LLMS.txtはAnswer.AI（Jeremy Howard氏のチーム）が提唱した標準仕様で、サイトの内容をLLM向けに簡潔にまとめたファイルを置くというもの（robots.txtやsitemap.xmlの概念に近い）。Googleはこれを使わない（AI Overviewsのランキングには影響しない） 他のAIクローラー（Claude・ChatGPT等）については不明 実害がある施策ではなく、Googleに効かないというだけ要するに「Googleには意味がない」が正確な表現で、「全てのAIに無意味」ではない。コストをかけてまで対応する優先度は低いが、「詐欺的なハック」と混同しないようにしたい。 実際に効く施策：3つの軸 軸1：非コモディティコンテンツの制作 Googleが「非コモディティコンテンツ」と呼ぶのは、「どこにでもある文章ではない内容」のことだ。 著名SEOコンサルタントのLily Ray氏はこう説明している。「AIだけのワークフローでは、実際の製品テスト、個人的な失敗、独自の意見、本物の感情——読者が信頼して価値を見出す核となる要素を提供できない」具体的に何を入れるか：実際に使った・試した一次体験 数字つきの具体的な結果 失敗した話（成功談だけのコンテンツより信頼性が出る） 「なぜそう考えるか」の個人的な見解軸2：パラグラフ・ライティングの習得 AIに引用されやすい文章の書き方は存在する。ただし、それは「AI向けの特殊テクニック」ではなく、60年以上前から存在する「パラグラフ・ライティング」という文章技法だ。 パラグラフ・ライティングの基本構造： ① トピック・センテンス（この段落で何を言うかを最初に宣言） ② サポーティング・センテンス（理由・根拠・例を書く） ③ コンクルーディング・センテンス（結論を再度まとめる）4つのルール：Unity（統一性）：1つの段落には1つのテーマ Coherence（一貫性）：前後関係が論理的でわかりやすい Development（展開性）：主張に具体的な根拠・数値・例をつける Length（適切な長さ）：長すぎず短すぎず特に Development を意識すると、AIが引用しやすい具体的な根拠入りの文章になる。 AIが特に拾いやすい情報の型：具体的な数値（「約50%高い」「30施設中15施設」） 明確な時間表現（「2026年第1四半期」「2026年5月12日」） 引用元がある主張（「Shopifyの調査によると」）軸3：第三者言及の獲得 旅館調査のデータが示した最重要の発見がある。 AI引用される施設とされない施設の差は「公式サイトの完成度」ではなく「第三者からの言及の蓄積量」にある。「生成AIは公式情報よりも、権威性のある第三者——業界の編集者・ジャーナリスト・専門家——による言及を優先的に引用する傾向があります」具体的な施策：専門メディアへの寄稿・取材対応 業界コミュニティでの発信・登壇 信頼性の高いサイトからのリンク獲得（従来SEOと同じ）本当に構造が変わる部分：AIエージェントによる取引 テキストコンテンツのAEOは従来SEOの延長だ。しかし、AIエージェントがユーザーに代わって商品を検索・比較・購入するという動きは、構造的に全く別の話だ。 Shopifyの2026年Q1データではAI経由トラフィックが前年比13倍に成長し、AI経由のCVRは通常オーガニック検索の49%高いことが示されている。AIが「比較検討を圧縮」して直接商品ページへ誘導するからだ。 このエージェントコマースへの対応は、コンテンツ最適化ではなく サイトの構造・機械可読性・スキーマの問題だ。特にEC・小売サイトでは独立した対応が必要で、詳細は別記事（小売業向けAIエージェント対応）で扱う。 まとめ：やることと捨てること優先度 施策 理由高 一次体験・独自データをコンテンツに入れる 非コモディティ化がAI引用の鍵高 パラグラフ・ライティングを身につける AIが理解・引用しやすい構造中 第三者メディアへの露出を増やす AI引用の決め手は外部からの言及低 従来のテクニカルSEO継続 基盤として必要だが差別化には不十分EC限定 AIエージェント対応（構造・スキーマ） 別記事参照不要 チャンキング・AI専用コンテンツ書き直し Googleが公式に否定入門編で構造の変化を掴んだうえで、上級編では2026年の実データを軸に戦略設計を読み解く。
AI検索時代のSEO、何が変わった？ 初心者が最初に知るべき5つのシフト
「SEOってまだ意味あるの？」 「AIに何か特別な対策が必要？」 ——検索の話題になるたびに、この2つがセットで出てくる。私はどちらも半分正解で、半分は勘違いだと思っている。土台は変わっていないが、勝ち方の設計は変わった。 あなたはどうだろう。AI検索の話は、まず全体像から掴みたい派？ それとも具体的な施策リストから入りたい派？ 私は前者派だ。難しい用語（LLMO・GEO・AEO）は中級編に任せて、ここではまず「構造の変化」だけ掴んでほしい。 この記事で伝えること AIが検索結果に入り込んできた2025〜2026年、SEOの世界で何が変わり、何が変わっていないのかを整理する。 変化1：検索結果の上に「AIの答え」が出るようになった 2024年以降、Googleで何かを検索すると、リンクの一覧が出る前に「AI Overviews（AIによる概要）」という要約が表示されるようになった。 Googleが「あなたの代わりに答えをまとめてあげる」機能だ。 ユーザーへの影響：答えがその場で読めるので、そのままリンクをクリックしない「ゼロクリック」が増えている。 サイト運営者への影響：検索1位でも、AIに要約されると流入が減る可能性がある。 ただし、これは「SEOが終わった」という意味ではない。GoogleはAI検索においても「これまでのSEOのベストプラクティスは引き続き有効」と公式に述べている。土台は変わっていない。 変化2：「キーワードに合わせる」から「人を理解する」へ 2000年代のSEOは、ユーザーが検索するキーワードに文章を合わせることが中心だった。 2013年の転換点 Googleはアルゴリズムを更新し、「言葉の一致」より「検索の意図」を重視するようになった。「品川駅近くのパーキング」と検索したら、「駐車場」と書いたページもヒットするように。 2026年の現在 生成AIが一般的な質問に直接答えるようになったため、キーワードを意識したコンテンツを作ることの意味はさらに薄れている。 SEO歴30年のDMM・渡辺隆広氏は断言する。「キーワードからコンテンツは作れません。コンテンツを企画するなら、人を理解することです。キーワードは、人を理解するためのツールの1つとして使ってください」変化3：「書けばいい」から「読まれる理由をつくる」へ かつては記事の量を増やせば流入が増えた時代があった。しかし今、Googleはページを読んだユーザーが「満足したかどうか」を評価軸にしている。 Googleが「非コモディティコンテンツ」と呼ぶものが重要になっている。これは「どこにでもある文章ではない、独自の視点がある内容」のことだ。 AIが出力するような「平均的で無難な文章」は評価されにくい。現場で得た体験、失敗談、具体的なデータ、個人の見解——これらが「非コモディティ」の正体だ。 変化4：「自分のサイトだけ最適化する」から「ネット全体に存在感を持つ」へ 旧来のSEOは「自分のページを良くする」ことが中心だった。AI時代に新たに重要になったのが「第三者からどう語られているか」だ。 国内温泉地の旅館を対象にした調査（2026年5月）では、調査した30施設のうち半数がChatGPT・Perplexity・Google AI Mode のいずれにも「一度も引用されない」ことがわかった。 引用される施設とされない施設の差は、公式サイトの完成度ではなく 「メディア記事・観光ガイド・専門家による評価など、第三者からの言及の蓄積量」 にあった。 変化5：「検索ランキング」から「AI引用」という新しい指標へ 従来のSEOの目標は「検索結果の上位に表示される」ことだった。AI時代に追加された目標が「AIの回答に名前が出る」ことだ。 ただし、これは「別の施策が必要」という意味ではない。 Googleはこう言っている。「回答エンジン最適化（AEO）や生成エンジン最適化（GEO）と呼ばれる手法がよく語られていますが、提案されている多くの施策は効果がなく、Googleの仕組みによってもサポートされていません」巷に出回るAI対策の多くは、Googleが「やらなくていい」と言っているものだ。 まとめ：本質は変わらない項目 旧来のSEO AI時代のSEO評価軸 キーワードの一致 ユーザーの満足度対象 自分のサイト内 ネット全体での評判コンテンツ 量・網羅性 独自性・一次体験目標 検索順位 検索順位＋AI引用変わっていないこと 良いコンテンツが基本 良いコンテンツが基本変わったのは手段の一部だ。「良いコンテンツを作る」という本質は変わっていない。 次の中級編では、「やってみたが効果がない」という人向けに、LLMO・GEO・AEOの実態と、正しい実践方法を整理する。
GCAOで組むプロンプトの基本
「この資料、なんかしっくりこない」 「AIに書かせたはずなのに、自分の言いたいことが出てこない」 ——生成AIを使い始めた頃、私はよくこう感じた。指示は出しているのに、返ってくる文章が他人の意見のままで、自分の判断が乗っていない。 あなたはどうだろう。プロンプトは毎回その場で考える派？ それとも、型を決めておいて再利用する派？ 私は後者に寄せている。出力に自分の意思を取り込むには、プロンプトでルール作りをしておくのが近道だと思っている。今回は、その型のひとつである「GCAO」について整理する。 プロンプトに「理論」を入れる理由 生成AIのプロンプトには、ときどき理論を入れると効く。 LLMには世の中の大抵のことが学習データとして残っている。「A理論」みたいに、書籍やフレームワークとして流通している考え方を名前で渡すと、その枠組みの中で推論してくれる。答えの方向をコントロールしやすくなるわけだ。 GCAOも、その理論のひとつだ。議題（アジェンダ）があるなら、Goal・Context・Action・Output Formatの4つを意識したほうが、AIも迷いにくい。 GCAOとは？ GCAOは、プロンプトを4つの要素に分けて考えるフレームワークだ。Goal — 何を達成したいか Context — どんな前提・背景で考えるか Action — 具体的に何を実行するか Output Format — どんな形式で返すか順番に見ていく。 Goal：目標を言語化する Gは「目標をどこに設定するか、何をしたいのか」だ。 ここが一番ブレやすい。質問する側が、自分でも言語化しきれていないことが多い。だからこそ、プロンプトに「まず私の目的を確認してから答えて」と書いておく手もある。AIに質問を促させて、思考を整理しながらゴールを固める——逆利用もできる。 「要約して」だけでは弱い。「この記事を、初めてこのテーマに触れる人向けに3段落で要約して」まで落とすと、Gがはっきりする。 Context：文脈と「言葉の裏」を決める Cは「文脈とか言葉の裏を、どう処理するか」だ。 必要以上の推測をさせるか、それ以下でも許容するか。質問者の意識の外にあるものまで、AIに補完させるかどうか——ようは、その問題だ。 例えば「ブログ記事を書いて」とだけ言えば、AIは一般的なブログの型で書く。でも「ですます調は使わない」「一人称は私」「段落は空行で区切る」とCを足せば、出力の温度が変わる。 Cが薄いと、便利な汎用回答が返る。Cが厚いと、あなたの文脈に寄った回答になる。 Action：実行内容を具体化する Aは「実行」だ。GとCで概ねの方向性が定まっていれば、ここでやることを明確にできる。 とはいえ、複数の思考や視点が必要な場面もある。AIが便利なのは、A/BテストではなくA〜Zテストを一気に出しやすいことだ。 「案を3つ出して」「賛成派・反対派・中立の視点で整理して」とAに書けば、私はその中から選ぶだけで済む。複数の答えを並べてもらうことで、出力への納得度が上がる。 Output Format：出力先を固定する Oは出力フォーマットだ。ファイル形式や構造を指定する。 テキストならtxtやMarkdown、表ならCSVやExcel形式、資料ならスライド構成——必要としている書類の形式に沿った出力を指定したほうが、AIも迷わない。 「パワポの資料を作って」と指示するだけで、それっぽいアウトラインが返ってくる。コードなら言語とファイル名、記事なら見出しレベルと文字数——Oで先に決めておくと、後から整形する手間が減る。 特に、出力したいコードや文章については、アウトプット先を固定するのは重要だ。「どんなフォーマットにしよう」と悩むクッション時間がなくなる。 GCAOの実例 たとえば、ブログ記事の下書きを頼むとき、私はだいたいこんな感じで組む。 【Goal】 このテーマについて、読者が「自分ごと」として考えられる記事の下書きを作る。【Context】- 読者は生成AIを触ったことがあるが、プロンプト設計は未経験 - ですます調は使わない。一人称は「私」 - 専門用語は初出で短く説明する【Action】1. リード（問いかけ＋私の立場）を書く 2. 本論を3つの見出しで展開する 3. 各見出しの下に具体例を1つずつ入れる 4. 反論になりそうな点を1つ拾い、短く応答する【Output Format】 Markdown。見出しは ## と ### のみ。箇条書きは最小限。GCAOと名前は付けていなくても、中身はこの4ブロックに収まっていることが多い。 このプロンプトは頑張るべきか GCAOは、まあまあ基本的な内容だ。私は意識しているわけではないが、だいたいこの通りにプロンプトを組んでいる。いつも通りでやれば、それなりにいい感じになる。 もしGCAOを名前として覚えていないなら、ロジックを登録しておくのが手堅い。Cursorのルール、Claudeのプロジェクト指示、Obsidianのテンプレ——環境ごとに「GCAOで組め」と短文で書いておけば、毎回フルで説明しなくても動きやすくなる。 頑張りすぎる必要はない。ただ、出力がしっくりこないときに「Gのどこが曖昧だったか」「Oを指定し忘れていないか」と振り返るチェックリストとして使う価値はある。 まとめ：型で自分の意思を載せる 生成AIの出力に自分の意思を取り込むには、プロンプトでルールを先に決めておくのが近道だ。GCAOはそのためのシンプルな型で、Goal・Context・Action・Output Formatの4つを埋めていけばいい。 理論やフレームワークを名前で渡すと、LLMはその枠の中で考えてくれる。毎回ゼロから指示を考えるより、型を再利用したほうが、選ぶ時間に集中できる——私はそう考えている。
Claude CodeをAPIで叩いて5億請求がきた会社があるらしい
「Claude CodeをAPIで回して、5億円の請求が来た」 ——SNSでそんな話を見かけると、私は「そらそうだろ」と同時に、別の感覚も湧く。サブスクの範囲では処理しきれない問題が、企業にはちゃんとあるんだな、と。 あなたはどうだろう。AIの月額料金、成果が見えるまで払い続ける派？ それとも「使いすぎたら赤字になるから、上限を決めて使う」派？ 私は後者に近い。だからこそ、定額プランとAPI従量課金の境目で、何が起きやすいのかを整理したい。 APIで利用しないといけないのか Claude Codeの話題は多い。でも実際にどう使っているか、というインタビューは少ない。 まあ守秘義務もあるっちゃあるし、大っぴらに言えないことも多いことは理解できるし、してほしい。 企業のプロジェクトに特化したプロンプトを公開するわけにもいかないし、その企業が「このAIを使っている」とわかれば、それだけで攻撃対象になりかねない。プロンプトインジェクションを仕掛けるにも、モデルを特定できた方が動かしやすいからだ。 生成AIのクラウドサービスの大半は、サブスクによる月額制で使用量が決められているパターンが多い。 一方で、AnthropicとSpaceXが共同することで、Claudeの使用制限はかなり緩和された。以前はProプランでも、1日に2回ほど利用上限に当たれば週間制限にひっかかるほどだったが、今は1日4回の上限にいっても、多少余るくらいになっている。 ということは、だよ。 個人ユーザーにとっては、サブスクの世界が少しマシになった。でも企業の話は別だ。 企業には、サブスクでは足りない問題がある エンタープライズやビジネス向けの法人プランはある。ただ、社内でアカウントを共有する運用には限界がある。 定額プランは時間と週間でリミットがかかるのが当たり前だ。最上位のMax$200でも、足りない人は足りない。並列でCLIを回す、複数プロジェクトを同時に走らせる、夜間バッチで大量のコードレビューを回す——こういう使い方をすると、サブスクの枠はすぐに枯渇する。 そこで足りない分はAPIを使う、という流れは自然だ。 APIは際限なく使える。大掛かりな開発では、従量課金の方が柔軟に見える。だから「Claude CodeをAPIで叩く」という選択が起きる。 ただ、柔軟さの裏返しがコストだ。サブスクなら月200ドルで頭打ちだが、APIにはその上限がない。使えば使うほど請求が伸びる。5億円という数字が話題になったのは、その極端な例だろう。 共有より、個人アカウントを渡す発想 企業向けプランを契約して社員全員で共有するより、個人にアカウントを与えて「生成AIを使うならそのプラン料金を会社が払う」——この発想の方が、これから増えていくのではないだろうか。むしろ個人アカウントを企業で使うスタイルが当たり前になるほうが柔軟ではないだろうか。 考え方としては、個人につける最大200ドル/月の秘書か部下の役割だ。必要経費として計上しやすい。使った分だけではなく、定額で予算が読める。共有アカウントで「誰が使いすぎたか」がわからない問題も避けられる。 とはいえ、社員全員にMax20を配るのは現実的ではない。開発部門だけ、AIを常用する人だけ、プロジェクト期間中だけ——そういう線引きが必要になる。全員に渡せば、使わない人の分も固定費になる。 私が言いたいのは、共有でリソースを奪い合うより、使う人に個別枠を渡す方が健全、という方向性だ。サブスクの上限緩和は、その前提を後押ししている。 200ドル分をAIで稼げるか ただ問題があるとすれば、月200ドル分をAIで稼げるか、という話だ。 生産性は上がるだろう。でも生産するにも「作るもの・構想」がなければ何も始まらない。プランを立てるのが一瞬で終わるからこそ、スピーディに動く必要がある。 資料作成が5分で終わるとしても、それで何ドルの利益が生み出しているのか計算したことはあるだろうか。将来的には200ドル分を回収している可能性はあるかもしれない。でも、その日に作った資料は企業利益の内訳からすると、どの部分でいくらの価値があるのか——。 ここを考えている人がどれだけいるのだろうか。 AIに任せるのであれば、働かせているAIにお金を払うという考え方を、もう少し柔軟に持つ必要がある。月200ドルの秘書が、月50万円分の仕事をこなすなら安い。月5万円分しか生み出さないなら高い。人間の採用と同じ構造だ。 個人なら「自分の時間が節約できたからOK」で済むこともある。企業なら、部門の売上・コスト削減・リードタイム短縮と結びついているかが問われる。 API従量課金と「5億請求」の意味 API利用だけで高額請求される話は、以前からある。5億円が事実かどうかはここでは問わない。仮に5億円請求されたとしても、5億円以上をそれで稼いでいるなら、経営判断としては問題にならないはずだ。 5億円以下、あるいはその3分の1程度の成果しかなかったからこそ、問題視された——そういう読み方ができる。請求額そのものより、投下コストに対するリターンが合っていないことが本質だ。 仮にAPI料金を必要経費として計上できたとしても、予算上限を超えれば赤字になる。場合によっては、エンジニアの給料より高額になる。人より高速で大量にコーディングはできる。でも開発スピードを上げて量を重視するだけでは、レビュー負債や品質問題が後から来る。 人間によるチェックをあわせて質を重視する。際限なく働かせる手段としてAIを使うのではなく、使うべきところだけに注力する——この使い方が、これから最適化されていくのではないだろうか。 神プロンプトより、回収できるか 「AIすごいすごい」は簡単だ。使うのも簡単だ。 それを使って生産性が本当に上がっているのか。売上に関わっているのか。AIの利用料に匹敵する成果が出ているのか——こういう問いがないと、日本は生産性が弱いまま終わってしまうだろうなと、私は思っている。 神プロンプトでキャッキャしている段階は、どの組織にもある。問題はそこで止まることだ。プロンプトの巧拙より、何を作り、いくらで売り、いくら削減したかを測れているかの方が重要になる。 生成AIのプラン設計も、いずれそちらに寄っていくはずだ。無制限に使わせるAPIと、定額で上限のあるサブスク。その中間に「部門ごとの予算枠」「成果連動の課金」みたいな形が出てくるかもしれない。今はまだ、個人の感覚と企業の会計の間にギャップがある時期だと思う。 まとめ：コストより先に成果を測れ Claude CodeをAPIで叩いて5億請求——極端な例としては、サブスクでは足りない企業が従量課金に流れ、予算管理と成果測定が追いつかなかった、という絵に見える。 個人には月200ドルまでの定額枠を渡す発想は、共有より健全だ。ただ200ドル分を回収できるかは、ツールの問題ではなく事業の問題だ。私は、プランを選ぶ前に「このAIにいくら払って、いくら返ってくるか」を書けるかどうかを、先に確認したい。
CLI駆動のAIで思うこと
「ターミナルでClaude Codeを3窓並べて回す」 「バックグラウンドエージェントに丸投げして寝る」 ——SNSでこういう投稿を見ると、私はつい「それ、本当に必要？」と思ってしまう。効率化の話に聞こえるのに、並列数が増えるほど管理コストも上がるはずだ。 あなたはどうだろう。AIはチャットUI派？ それともCLIでローカルファイルを直接触らせる派？ 私は両方使う。ただ、どちらが上という話ではなく、用途で選べばいいと考えている。まずはCLI駆動が想定している使い方から整理してみたい。 CLI駆動のAIは、どんなユースケースを想定されているのか ブラウザのチャットUIとは違い、CLI駆動の強みはローカルファイルを渡して作業できることだ。リポジトリを読ませ、差分を書かせ、テストを回させる——コピペ地獄から解放される。 Git連携、スクリプト化、バッチ処理——「同じ作業を何度も繰り返す」場面で力を発揮する。ただ、複数CLIの同時稼働はPCリソースも分散させる。ターミナルを何窓も開いて回すことが、本当に効率につながるのか——私はそこに疑問を持っている。 CLIを使うメリット ファイル操作がそのまま成果物になる。チャットUIだと、生成結果をエディタに貼り戻す手間が必ず挟まる。CLIなら、書き換え・保存・コミットまで一気通貫だ。 定常タスクに向いている。「毎朝このフォルダを要約してSlackに投げる」といった繰り返し作業は、CLIの方が運用しやすい。プロンプトを固定し、ログを残し、失敗時に再実行できる。 コンテキストがリポジトリ単位で保たれる。プロジェクト構造や既存コードの書き方を、毎回説明し直す必要が薄い。 CLIを使うデメリット 並列実行は万能薬ではない。複数エージェントを同時に走らせると、CPU・メモリ・APIコストが積み上がる。タスクが独立していても、結果の取りまとめは人間の仕事だ。 シンプルな相談には重い。「この文章、もう少し柔らかくして」程度なら、チャットの方が速い。CLIは起動・指示・確認のステップが増える。 コストの見え方が複雑になる。バックグラウンドエージェントとバッチ処理——どちらが安いかはタスク次第だ。並列数を増やすほど、見積もりは難しくなる。 例えばXの自動投稿とか 自動投稿するにも、まず「ネタ」が必要になる。 仮に100日分を100アカウント分作成したとしても、1日に投稿するのは最大100ポストだ。それを10並列で処理する必要があるのだろうか——私は疑問に思う。ネタ生成と投稿スケジュールは別問題で、並列化がボトルネックになるケースは意外と少ない。 こういう例は、CLI evangelism の典型だ。技術的には可能でも、ビジネス要件と噛み合っていない。メリットを語る前に、「本当にここが詰まっているのか」を確認したい。 チャットUIとの使い分け 私の基準はシンプルだ。探索・相談・下書き → チャットUI。思考を広げる段階は、軽い方がいい。 ファイル変更・定常タスク・再現性 → CLI。成果物がディスクに残る作業向き。同じプロジェクトでも、設計はチャット、実装はCLI——混ぜて使うのが自然だ。 まとめ：用途で選んでいい CLI駆動のAIは、ローカルファイル操作と自動化で強い。反面、並列実行や常時稼働は、リソースとコストの割に合いを見ないと過剰になりやすい。 あなたの用途で選んでいい。チャットベースでもCLIでも、自由に選んでいい。「CLI派」「チャット派」の正解争いより、今日のタスクに合う方を取る——それで十分だ。
AIと一緒に考えるには、最初の一歩が必要
「AIに聞いたら、すぐ実行した」 「結果、思っていたのと全然違った——でも誰のせいにすればいい？」 ——チャット型AIが当たり前になった今、私はこういう後悔をよく見る。AIの性能の問題ではなく、最初の一歩を誰が踏むかが曖昧なまま進んでいるケースが多い。 あなたはどうだろう。AIの回答を「正解」として受け取る派？ それとも「たたき台」として自分の判断と照合する派？ 私は後者でないと、「共に考える」にはならないと感じている。なぜそう言えるのか、順を追って整理する。 AIと共に、考える 私はAIと一緒に考えているのだろうか。 何かを考えて、指示をして、出てきた情報を鵜呑みにして、失敗している。失敗とまではいかないけど、あきらかに何かが足りていない。足りてないのは何だろうか。 AIの性能ではなく、私にそれが実現できるかどうか、だ。 AIの答えを信じるのではなく、私の意見を鵜呑みにしないことも考慮するべきだ。 「共に、考える」 チャット型AIが登場してから、人間の思考はより洗練されたのだろうか。私はそう思っていない。AIが出している回答は「計算からいくつかの選択を"私好みで"拾い上げている」にすぎない。 AIの答えが正しいと思うか、正しくないと思うか。これは可能性の問題である。 成功するかしないかも、可能性の問題。しかし、やらなければ成功率はゼロになる。 AIよりもあなたのほうが賢い AIよりも人間の方がまだ賢い。分野にもよるけど、最初の質問を出すのは人間で、回答を出すならAIが得意だ。これはググると同じような構造。 コンピューターが不得意なのは、ゼロから行動すること。 ようするに、デキる人間が苦手な「自分で仕事を探せない人」と同じである。 AIやプログラムは、指示されたことを愚直なまでに遂行する。それは性質の問題であるから変えようがない。自動車製造でコンベアなりゆったり動いているうちに、作業員がひとつひとつ仕事をして１台を完成させていく工程がある。プログラムは工程と作業をすべて理解してはいるが、コンベアを動かすなり人員配置をするのは管理する人間の役目。 例えコンベアをボタンひとつで動かせるとしても、プログラムはそう指示をしていないと、自律的に判断して動かしてはくれない。24時間稼働なら3交代になるだろうけど、交代するタイミングで人の作業はどうしても止まるから、そこでラインを止める必要がある。 引継ぎをして、準備して、コンベアを動かす。その指示を出すのがプログラムだったら、それはそれで人間様が反発するのではないかなと思う。 そう……。３交代制なら「この時間にコンベアを止めて、この時間には動かすべきだ！」とプログラムすることは簡単。でも人間とか世界は不条理なことが多い。必ずそのスケジュール通りに物事が進むとは限らない。だから目視で確認してから開始のスイッチを押すのがただしい。もしいるはずの人がいなかったら？必要な材料が最初の1時間で無くなるとしたら？作業を中断したとして、次の交代で数分後には自動で実行されてしまうぞ。 てなわけで、機械の弱点は「融通が利かない」ことが最大の弱点。 柔軟に行動することができるのは人間の特権であるともいえる。もちろん万人がそうとも限らないけれど、我々は自分の意思で道を選ぶことができる。 AIもプログラム・アルゴリズムでは"そう見える"んだけど、本質的には人間よりも判断能力は劣っている。人間に思い付かない判断をプログラムすることはできない。ここが大きな違いであるといえる。 計画は人間から始まる 何事も「成功」するには「計画」する必要がある。計画をするにしても、AIがゼロから考えてくれるわけじゃない。最初の一歩は私から出す必要がある。 AIに渡すべきなのは、完成した答えではなく、検証可能な仮説だ。「こういう方向で進めたい。反論と代替案を出してほしい」——この段階で初めて、AIは思考の相棒として機能する。 まとめ：最初の一歩は人間 AIと一緒に考えるとは、答えを委ねることではない。自分の問いを立て、AIの出力を疑い、最終判断は自分で下す——そのサイクルのことだ。 最初の一歩を踏むのは、いつだって人間側。そこを省略すると、どれだけ高性能なAIを使っても、「共に考えた」実感は残らない。
Claude Codeを使うならMaxプランが最適か
「Claude Code、Proプランで十分じゃない？」 「いや、並列で回すならMax20一択でしょ」 ——SNSで料金議論を見るたび、私は用途と支払い能力の両方で答えが変わる、と感じる。安いプランに含まれるからといって、ヘビーユース向けではない。 あなたはどうだろう。AIツールの月額、成果が見えるまで払い続ける派？ それとも「まず無料・最安で試す」派？ 私は後者から入って、詰まったら上げる派だ。Claude Codeの料金体系を、実際の使い方に照らして整理する。 Claude Codeの料金体系Pro: 月20ドル、週間の最大がある。 Max5: 月100ドル、Proの5倍の利用枠。 Max20: 月200ドル、Proの20倍。小規模開発ならProで十分。日常で使う簡単な質問とか、Codeでも小規模アプリを作る程度なら20ドルで十分ではある。 ここで使い切るようなら、100ドルプランを視野にする。 とにかく使い倒すなら200ドルのMax20が最適解。特にClaude Codeを常用するとか、PC内タスクをこなすのに使う目的なら最適解。 ProプランでもClaude Codeは含まれる。ただヘビーユーズには対応しておらず、基本的に数時間に1回の制限と週間のリミットが存在する。100ドル以上のMax5-20プランにおいては、週間制限などの最大上限こそあるものの、ヘビーユースにも対応することができる。 たまーにアプリ作成や文章依頼をするならProでもいいし、この場合は普通のチャットも活用することで2倍以上の活用が可能になる。100ドル以上はCLI駆動で並列同時作業をこなすようなケースを前提にしている。 問題は料金の支払いか 年契約なら割引が適用される。月課金が100ドルを超えるってことは、毎月15000円以上をコストに入れないといけない。これを支払うためにも、成果物でそれだけの収益性があるかどうかが鍵になる。 Cursorの60ドルとClaude20ドル。合計80ドルプランでおよそ月に1万円。これをなんとかするには、クラウドワークスなりで1万円以上の仕事を得るのが最適解——というのが、私の個人的な試算だ。 プラン選びの目安使い方 向くプランたまに質問・小規模コード Pro（月20ドル）週数回、中規模開発 Max5（月100ドル）CLI並列・定常タスク・常用 Max20（月200ドル）「最適解」は万能ではない。月2万円以上を課金する覚悟があるか——そこから逆算するのが現実的だ。 まとめ：用途でプランを選ぶ Claude CodeはProから使えるが、制限は厳しい。ヘビーユースやCLI駆動の並列作業ならMaxプランが現実的な選択になる。 安いプランで始めて、上限に当たったら上げる——それで十分だ。最初からMax20を選ぶ必要があるのは、すでに「毎日CLIで回す」前提が固まっている人だけだと思う。
シャドーAIとは何か、なぜ企業が問題視するのか
「会社のCopilot、使いにくいからClaude使ってる（バレないように）」 ——こういう発言を見かけると、私は「わかる」と同時に「それ、シャドーAIだ」と思う。どうも企業が推奨するのと違うAIを使うことが、シャドーAIと呼ばれているらしい。 あなたはどうだろう。社内で使えるAIがあっても、個人の方が精度がいいから別ツールを使う派？ それとも会社指定に従う派？ 私は後者を推奨したいが、前者に流れる理由も理解できる。リスクと現実のギャップを整理する。 なぜシャドーAIが問題視されるのか 社内で使うなら社内情報を使う必要があるし、それを活用するデータセットLLMにチューンする必要がある。なおかつ外部にデータが参照されないよう、企業内だけでデータが完結するセキュリティ対策が必須。 多くはOS準拠のCopilotが使われるわけだし、Officeを使っているならOffice365のCopilotなら使えるという制限をかけるのが妥当ではある。Copilotは知っての通り、Windows標準でありながら話題性はほぼゼロといっていい。性能が他に劣っているといわれるが、ベンチマークでの話。ちゃんと資料作成にコードライティングに画像生成もできる。 世間的にはChatGPTとClaudeが人気。これらのユースケースの紹介は数多いし、検索すれば大抵出てくるため引用されがち。だからこそClaudeに慣れすぎたせいで、Copilotが使いにくいとかいい結果がもらえないなどの理由で、ClaudeなりほかのAIを使うことをこっそりやっているケースをシャドーAIという。 ちゃんとリスクしかない 社内資料をもとに生成すると、そのデータを学習してしまうから、情報漏洩につながってしまう。厳密にはCopilotも学習はしているんだけど、社内クラウド想定のOffice365はチーム内だけの共有になる。だから外部からはLLM自体へのアクセスが不可能な仕組みになっているから、情報漏洩を防げるというわけ。 でもそれは建前という話でもある。 もともと生成AIはウェブからデータを集めるので、ウェブサイトに掲載されている資料はフォローされている。だからどこまでが秘匿情報なのかを明確にしたほうが、生成AIと賢く付き合える。 現実的な対処 資料作成ならむしろツールを作成したほうが早いケースもある。 なぜなら、資料のデータをもとにグラフを作成するとか、KWを入れてテキストを入れるとかなら、Pythonスクリプトでも実現は可能だから。 社内AIが使いにくいなら、個人の好みのAIに社内資料を流し込むのではなく、秘匿情報を含まない範囲でCopilotを使う 定型処理はスクリプト化する どうしても外部AIを使うなら、匿名化・要約済みテキストだけ渡す——この線引きが現実的だと思う。 まとめ：線引きが先 シャドーAIは「悪いツールを使っている」というより、セキュリティ境界を越えていることが問題だ。 Copilotが不満でも、社内資料をChatGPTに投げるのはリスクしかない。秘匿情報の定義を自分で決めてから、ツールを選ぶ——それが企業と個人の双方にとって安全な使い方だ。
Obsidian公式のobsidian-skillsがClaude運用を楽にする
「Obsidian、機能は知ってる。でも日常で使いこなせてない」 ——DataviewもCanvasも、存在は知っているのに導線に乗らない。私もそうだった。Obsidian公式が公開している AI 向けスキル obsidian-skills を触って、運用の腰が重くなくなった。 あなたはどうだろう。Obsidianは「メモの墓」になっていない？ それとも第二の脳として回っている？ 私は前者に近かった。obsidian-skillsが、後者に寄せるための土台に見えた。 obsidian-skills が効く理由 obsidian-skills は、AI が Obsidian の主要フォーマット（Markdown の癖、wikilink、Canvas など）を踏まえて動けるようにするためのスキル群です。 Obsidian には Dataview や Canvas、Kanban など、機能だけ見れば強い要素が揃っています。 ただ、すべてを自力で綺麗に書き切れる人は少ない。 だからこそ、AI に「Obsidian の作法」を教え込む仕組みがあると、運用の再現性が一気に上がります。 参考として、導入から使い方まで丁寧に説明してくれている動画があります。 Obsidian公式が公開したAI対応スキル(obsidian-skills)がめっちゃ使える！導入から使い方まで解説 - YouTube 私が「便利だな」と感じたのは、解説そのものというより、周辺ツールの存在を知れたことでした。 MCP で外部と繋ぐやり方もある一方で、Obsidian のウィンドウ内で回せる接続があるのは強い。 ブラウザや別アプリに視線が逃げにくいので、メモ環境としての一体感が残ります。 Canvas は「知っている」と「使う」が別問題だった Canvas の良さは薄々わかっていました。 プレゼンの土台としても向くし、情報を並べ替える画面としても優秀です。 一方で、実務に落とすまでが難しかったのも事実です。 存在は知っているのに、日常の導線に乗らない。 ここで強いのが、Mermaid で骨格を書きつつ、Canvas 側でグラフィカルに整えていける流れです。 「文章だけ」でも「図だけ」でもなく、往復しながら整えるのが現実的でした。 「Obsidian × Claude」を前提にすると、スキルの意味が変わる obsidian-skills で Obsidian 側の作法が固まると、次に効いてくるのが Claude Code のような CLI 前提の AI です。 コミュニティでは、Obsidian を中心に Claude 系ツールを組み合わせた運用を Claudian と呼ぶことがあります（呼び方は固定ではありませんが、置き換えとして便利です）。 ポイントは、チャットで雑談するより、ルールとスキルと実行環境を育てるほうが勝ちやすい、という話です。 Obsidian は「第二の脳」として語られがちですが、運用が乱れると単なるメモの墓になります。 obsidian-skills は、その設計コストを下げるための土台に見えました。 Claude Code の料金は読み替えポイント Claude Code は、無料枠だけで無制限に回せるイメージとは向き合いにくいタイプです。 現状、利用するなら 有料プラン前提で計画したほうが安全です。 Obsidian 側には、別モデルを使うプラグインもあります。 ただ、CLI で動かしてワークスペース単位で指示を回す用途では、Claude Code の設計が前提に近い場面が多いです。 月額が気になるなら、まずは「毎日触るか」「資産として残る作業か」で割り切るのが現実的です。 まとめ：作法をスキル化 obsidian-skills の本質は、単体のテクニックというより Obsidian を AI と共同運用するための共通言語に近いです。 MCP で繋げば広がりは作れる。 それに加えて、Obsidian 内で完結する道があると、日常の摩擦が減ります。 Obsidian を主戦場にしている人も、Notion メインで Obsidian をサブにしている人も、まずは「作法をスキル化して渡す」発想を試す価値はあると思います。
キーボードの赤軸・茶軸って何のこと？フィーリングで選ぶ
「赤軸がいいらしい」 「いや、打鍵感なら茶軸でしょ」 ——自作キーボード界隈では当たり前の会話だけど、初めて聞くと「軸って何？」となる。私も最初はスペック表を読んでも、フィーリングで「赤軸ってこんな感じ」を説明したいと思った。 あなたはどうだろう。キーボード選び、数字（触圧g）派？ それとも店頭や実機で触って決める派？ 私は後者だ。ただ、ECサイトでは試打できない。軸の名前は、触った感触のラベルに過ぎない——そのラベルを、文字だけでどこまで伝えられるかが今回の話だ。 軸選びって結局よくわからない メカニカルキーボードの「軸」とは、キーを押したときに反応するスイッチ本体のこと。Cherry MX系の命名が広く使われ、色で特性を区別する。 赤軸とか青軸といわれても、実際は「クリック音が変わる」「ストロークの長さが違う」といった話が混ざる。スペック表の触圧45gとか60gを並べても、メーカー・キーキャップ・基板の素材で体感は変わる。 ギークなら数字から打鍵感を想像できるかもしれない。でも初めての人にとっては、触って確かめるのが一番早いし確実だ。試せないなら、次善策として「こんな感触」と覚えるしかない。 他にも銀軸（低触圧・短ストローク）、黒軸（高触圧）などがあるが、入門では赤か茶かで十分だ。青軸は「音がついた茶軸」と思えばだいたい合う。 赤軸・茶軸・青軸、フィーリングで説明する 細かい説明より、日常の動作にたとえたほうが早い。以下はあくまでイメージで、実機とは必ずしも一致しない。でもECサイトの商品名だけを見て迷っているときの、最初の手がかりにはなるはずだ。 赤軸：スッと落ちる感触 赤軸（Linear）は、押し始めから押し切りまで抵抗がほぼ一定に増えていく軸だ。途中に段差がない。 たとえるなら、なめらかなレールの上を指先で滑らせて、最後にポンと底に当たる感じ。スイスイ落ちていくので、ゲームの連打や高速タイピング向きと言われる。 「カチッ」とした確認感はない。だから押し間違いに気づきにくい反面、指が疲れにくく、長時間の連打には向く。軽めに感じることも多い。 茶軸：カチッと引っかかる感触 茶軸（Tactile）は、押している途中で小さな段落——いわゆる「コツッ」——がある軸だ。越えるとスッと沈む。 たとえるなら、薄い段差のある段ボールを指で押し込む感じ。今このキーを押した、という確認が指先に返ってくる。タイピングの打鍵ミスに気づきやすい。 赤軸より情報量が多いぶん、少し重く感じることもある。プログラミングや長文入力では、この「押した実感」が好まれる人が多い。AIに長文プロンプトを打つなら、段落感のある茶軸の方が疲れにくい、という声も聞く。 青軸：クリック音が主張してくる 青軸（Clicky）は、茶軸の段落感に加えて、押した瞬間にカチッと鳴る軸だ。感触と音の二重で「押した」と教えてくれる。 たとえるなら、茶軸のコツッに、金属のクリップをはずすような音が重なる感じ。打鍵感を楽しむには最高だが、周囲にはうるさい。オフィスや図書館では避けたほうがいい。 自宅で一人、打鍵の気持ちよさを味わいたいなら青軸。静音が必要なら赤軸に静音リングを付けるか、メンブラン式キーボードを検討する——という棲み分けになる。 同じ「茶軸」でも、Filcoと安価な自作キットでは別物に感じることもある。色の名前は共通でも、中身のメーカーが違えば感触は変わる。 結局どれを選べばいいのか 用途の目安はこんな感じだ。用途 向きやすい軸ゲーム・高速タイピング 赤軸、銀軸プログラミング・長文入力 茶軸打鍵感を楽しむ（自宅） 青軸静音・オフィス 赤軸（静音リング付き）、メンブランとはいえ、好みの問題でもある。とにかく速く打ちたいなら赤軸。押した感じを大事にしたいなら茶軸。迷ったら、最初から1種類に決め打ちしないほうがいい。 試す前に確認しておきたいのは次のあたりだ。テンキーレス／フルサイズ／分割のどれが手に合うか キーキャップのプロファイル（ASA、Cherry等） ホットスワップ対応か（軸を差し替えられるか）店頭で触れないなら、ホットスワップ基板＋試打用スイッチセットが現実的だ。数種類の軸を数百円〜千円台で買い、自分のキーボードに差して比較できる。YouTubeのタイピング音動画も、音の参考にはなる（感触そのものは別物だが）。 自作キーボードをやっている人なら、軸選びは一度きりの決断じゃない。差し替えられる環境を先に作るほうが、結果的に満足度は上がるわけだ。 よくある質問 赤軸と茶軸、どっちがタイピング向き？ 一般的には茶軸がタイピング向きと言われる。途中の段落で押し間違いに気づきやすいからだ。ただ、軽く速く打ちたい人は赤軸を好むことも多い。正解はない。 青軸はうるさい？ はい、周囲にはうるさい。自宅や個室なら問題になりにくいが、オフィスや共有スペースでは避けたほうがいい。静音が必要なら赤軸＋静音リングや、メンブラン式を検討する。 ECサイトで買うとき、軸はどう選べばいい？ 試打できないなら、用途表を参考に赤か茶で絞るのが無難だ。迷ったらホットスワップ対応のキーボードを選び、あとから軸を変えられるようにする。試打用スイッチセットを別途買う手もある。 銀軸・黒軸は何が違う？ 銀軸は触圧が軽くストロークが短い。ゲームの高速入力向き。黒軸は触圧が重めで、誤押ししにくい。いずれも赤軸と同じリニア（段落なし）系だ。入門では赤・茶・青の3色を押さえれば十分だ。 まとめ：触って決めていい 赤軸・茶軸は、スペック競争のラベルではなく、打鍵フィーリングの名前だ。 赤はスッと落ちる。茶はカチッとわかる。青は音まで付いてくる——この3つを頭に置いておけば、商品ページの「〜軸」表記が少し読めるようになる。 数字だけで選ばず、可能なら実機か試打セットで触る。みんな当たり前に言っている軸の話も、一度手で確かめれば一気に腑に落ちる。
防音マスクでAIに音声指示する——ゲーミングデバイスの別用法
「リビングでAIに喋りかけたい。でも家族がいる」 ——防音室は高い。クリップマイクは周囲の声も拾う。私が盲点だったのが、ゲーミング向けの防音マスクだ。AIエディターは文字入力より音声入力の方がコンテキスト精度が上がる、という評判もある。 あなたはどうだろう。AIへの指示、タイピング派？ それとも喋る派？ 私は最近、後者を試したくなっている。防音マスクがそのカテゴリに入る。 防音マスクがゲーミングデバイスとして紹介される理由 ゲーミングデバイスとして紹介されることが多い。ようはゲーム中のコールなど通話がうるさいといわれることが多いのだ。防音室を導入するとなると費用がかさむ。 例にあげる「VEKTA 防音マスク（ゲーミングマスク）」は、-30dBの軽減がされるマスクタイプのマイクデバイス。これを装着して喋るだけでいい。 -30dBの軽減はどのくらいの効果があるのか 怒鳴り声は貫通するだろうけど、普通の会話内容なら30dB以下だったはず。それを思うと軽減率がかなり高いとわかる。価格は27000円くらいなので、小型の防音室よりも安いし軽減率も大きい。 問題があるとすれば いちおう「声がくぐもらないように処理される」ことが前提にはなっている。とはいえ、蒸れはどうしようもないし息苦しくなるかもしれない。自分の二酸化炭素でどうにかなる可能性は通気を考えると可能性は低いが、リスクがゼロじゃないことに留意。 長時間の装着は向かない。30分〜1時間の音声セッション単位で使うイメージが現実的だ。 AIに音声指示するのに適していると評判 最近のAIはテキストよりも音声入力のほうが正確に反映されるらしい。 思考しながらだとテキストを打ち込みながらがいいだろうけど、コンテクストをより多く獲得するなら、実現したいことを喋りかけるほうがいい。 ゲーミングデバイスよりも、AIに音声入力するなら、マスク型デバイスでもなく汎用的に使えるクリップマイクがいいかもしれない。 マスク装着型デバイスとしては、村田製作所がCEATEC AWARD 2025で受賞している「mask voice clip」がある。 https://corporate.murata.com/ja-jp/newsroom/news/company/general/2025/1007 マスク＋マイクがこれからの標準か？ マスクをつけての会話はどうしてもくぐもった感じになる。そこをデジタル技術で解決するのがらしい対処だと思う。 防音マスクは「周囲を静かにする」だけでなく、マイクに届く声をクリアに保つ設計になっている製品が増えている。AI音声入力の普及と、在宅・家族同居の環境が重なって、ニッチが広がっている印象だ。 選び方の目安優先したいこと 向く選択周囲への配慮・防音 防音マスク（VEKTA等）軽量・汎用 クリップマイク完全静音 防音室（予算に余裕がある場合）私は防音室ほどの投資はできないので、マスク型は「試す価値がある」ラインだ。 まとめ：ゲーミング枠の外で見る 防音マスクはゲーム配信者向けに見えがちだが、AIへの音声指示という用途にもハマる。 27000円程度で-30dB——防音室の代替としては現実的な選択肢の一つ。蒸れと装着時間だけは許容できるか、試す前に確認したい。
ハイスペックPCは買うよりリース？リユース・レンタルの選び方
「AI開発用にGPU積みたい。30万超える…」 「ネカフェで試してから決めようかな」 ——ハイスペックPCは、買うと一発で資金が消える。私がメモに残していたのは、ハイスペックを買うよりリースがいいか、試しに使うならネカフェもあり、という話だ。 あなたはどうだろう。PCは買い切り派？ リース・サブスク派？ 私は用途次第だが、試してから決める選択肢を知っておく価値は大きいと思う。 選択肢の整理 一括購入（新品）メリット：所有権が明確。カスタム自由度が高い。 デメリット：初期コストが高い。3年後の価値は大幅減。リユース（中古・認定品）メリット：同スペックなら新品の半額以下も。企業向けリース返却品は状態が良いことも。 デメリット：保証期間が短い。最新GPUは流通量が少ない。レンタルメリット：1週間〜1ヶ月単位で試せる。イベント・短期プロジェクト向き。 デメリット：長期だと買うより高くつく。リース（法人・個人向け）メリット：月額固定。更新サイクルとセットで管理しやすい。 デメリット：総支払額は買切より増えることが多い。どんな人に向くか状況 おすすめまずAI開発を試したい ネカフェ、短期レンタル1〜2年使って更新したい リース、認定リユース5年以上同じ構成で使う 一括購入（自作含む）経費処理したい（フリーランス） リース（要確認）Claude CodeやローカルLLMを「本気で回す」前に、そのスペック本当に必要かをレンタルで確認する——これだけで無駄な30万を防げる可能性がある。 リユースを選ぶときのチェックポイントSSDの健康度（書き込み寿命） GPUの熱履歴（マイニング用途でないか） 保証の有無と期間 OSライセンスの正規性企業向けリース返却品は、3年程度で入れ替えられるため、「十分速いが最新ではない」構成が手に入りやすい。 ネカフェという選択 試しに使うならネカフェもあり、というのは地味に正しい。1時間数百円で、自分の用途（IDE＋AI＋ブラウザ多数タブ）が回るか体感できる。 「家に同じ環境を持つ」決断の前に、外でストレステストする価値はある。 まとめ：所有より試用 ハイスペックPCは、買うか買わないかの二択ではない。 リユース、レンタル、リース——更新サイクルと初期コストで選べば、同じ予算でも選択肢は広がる。AI開発の波で焦って買う前に、一度「借りる」手を検討してほしい。