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を使うと仕事が遅くなる？ワークスロップとパイロット思考
「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時代：ゲームの登場人物を生成するかオリジナルにするか
「ゲームのキャラ、生成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）
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派」「チャット派」の正解争いより、今日のタスクに合う方を取る——それで十分だ。
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に投げるのはリスクしかない。秘匿情報の定義を自分で決めてから、ツールを選ぶ——それが企業と個人の双方にとって安全な使い方だ。