Showing Posts From
自動化
ブログ別ペルソナで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音声・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はその一部にすぎない——というのが、私の現時点での見立てだ。
DX人材を見極めて獲得する——地図が先、人材は後
「DX推進担当を募集します」 「DX人材が足りない」——求人票や業界記事で、同じような言葉を何度も見かける。私はそのたびに、少し首をかしげてしまう。足りないのは人材なのか、それとも「DXで何を実現するか」が決まっていないポジションなのか。 あなたはどうだろう。DX担当の採用で、資格や肩書きをまず見る派？ それとも、現場の業務を理解しているかを優先する派？ 私は後者に寄せている。DXは売上を加速させる魔法ではなく、人間が入り込む余地をなくすほど自動化を進める話だ。機械にできることと、人間にしかできないことを切り分けたうえで、自社に合った形に落とし込む。人材選びも、その前提がないとミスマッチになる。 先に決めるべきは「DXで何を実現するか」 DX担当者——あるいは推進責任者——が最初にやるべきことは、人を探すことではない。実装の要因、つまり何を自動化し、何を人に残すかを決めることだ。 世間のDX像は、どうしても事務作業をPCに移すイメージに寄りがちだ。紙をPDFにする、請求書をスキャンして帳簿に入れる。これは20年前からOSやクラウドサービスでできることで、DXというより既存ツールの導入に近い。 本当の論点は別のところにある。アナログの性質とデジタルの性質、どちらも理解していないと、「なぜデジタル化するのか」が説明できない。 登り釜の温度管理を例にする。火の守り手が24時間つかずはなれず番をする現場を、デジタルでどう置き換えるか。テスラのロボットが薪を入れること自体は可能かもしれない。だが、どこに薪を入れるか、つむのか減らすのか——現場の判断がハードに落ちていないと、ソフトだけでは動かない。AIが担えるのは知識面までで、溶けないコードで熱源に手を突っ込むロボットは、別の設計課題になる。 こういう現場があるからこそ、DXは「業種の成功事例をコピーする」話ではない。鍛冶師の補助をロボットに任せる話と、事務をPCでやる話は、同じDXと呼んでも中身が違う。同業他社の事例は参考になることもあるが、無関係な分野の事例は、ときに何の手がかりにもならない。 DX担当が選ぶべき実装要因は、ざっくり次の3つに整理できると思っている。 機械に任せられる作業——繰り返し、ルールが明確で、例外が少ないもの。 人に残すべき判断——例外処理、顧客対応、安全や品質に関わる最終責任。 自社固有の制約——設備、慣習、法令、そこにいる人の技能。 この3つが曖昧なまま「DX人材」を探し始めると、採用しても動かない。担当者が先に地図を描くべきだ。 資格と専門学校は、人材確保の答えにならない IPAには「DX認定制度」がある。経産省のお墨付きで権威性は上がる。だがこれは「うちはDXやっています」と認めてもらう制度で、人材を確保する手段ではない。審査に60日かかるなら、その間にもっと現場を直せる余地はあるだろう。 世間にアピールする用途と、採用基準を混同している会社が少なくない。皆が本当に知りたいのは「どうやってDXしたのか」のほうだ。 一方で、DX専門の学校や養成講座も増えている。何を学ぶのか——紙をPDFにすればデジタル、というレベルなら、Windowsのスキャン機能のほうが早い。請求書のOCRや帳簿連携は、既存のクラウドや生成AIでも実現できる。 そこで学んだ人が世間では「DXエキスパート」に見える。でも現場では、頭でっかちでソフトもハードも弱く、エンジニアと話がかみ合わない——そんなコンサルタイプになるリスクもある。体系的に「これが正解」と教えるカリキュラムと、自社に最適化するDXは、そもそも方向がずれやすい。 DX専用の資格が決定的に役立つわけでもない。重要なのは、資格の有無ではなく、アナログの現場とデジタルの手段の両方を理解しているかだ。 経営者・人事が取るべき獲得の順番 経営と人事の視点では、獲得策を「外から買う」か「中で育てる」かに分けがちだ。私は、多くの中小企業なら中で育てるほうが現実的だと思っている。 理由は単純だ。DXは自社に最適化するべきもので、教科書どおりの型が存在しない。現場を知っている人にソフト面を足すほうが、未知の業界からDX担当を迎えるより、発注も指示もしやすい。ソフトを理解していれば、SEへの依頼内容が具体化する。「どこのあれをこうしたい」が言語化できる人材は、外から採用するより社内にいることが多い。 経営者がやるべきことは、リスキリングの時間と予算を確保することだ。人事がやるべきことは、DXという肩書きではなく、業務改革に耐える人物像を要件に落とすことだ。具体的には次のような順番が現実的だろう。 現場のベテランや中堅から、業務知識があり、変化に抵抗が少ない人をリストアップする。 小さな自動化やデジタル化を任せ、成果と学習速度を見る。 外部のエンジニアと会話できる人に、発注・要件定義の役割を足していく。 全社DXの象徴役として肩書きを付けるのは、その後でも遅くない。 外注や採用は、地図が描けてからのほうが失敗が少ない。「DX経験3年以上」だけ書いた求人票は、ミスマッチの温床になりやすい。 見極めるポイント——肩書きより会話で確認する 面接や社内登用の場で、私が重視するのは次の4点だ。 「うちのDXで何が変わるか」を30秒で言えるか。抽象論だけなら、推進役にはなれない。 アナログ現場の制約を尊重しているか。「全部クラウドで」だけの人は危ない。登り釜の例のように、ハードと慣習の壁を知っているか。 エンジニアと対話できるか。ソフトの話がかみ合わない時点で、実装フェーズで止まる。完璧な技術力は不要だが、要件を構造化して渡せるかは必須に近い。 自動化と人の役割を切り分けているか。「AIですべて」は設計ではない。何を人が見るかまで言える人を選びたい。 逆に、DXファシリテーターかオペレーターかといったラベルにこだわる必要はない。ファシリテーションが得意なら会議設計、オペレーションが得意なら現場導入——役割は分かれる。大事なのは、ラベルではなく、自社の実装要因にフィットするかどうかだ。 まとめ：地図が先、人材は後 DX人材不足の多くは、本当は人不足ではなく、何をDXするかの地図不足だと私は考えている。担当者が機械と人の境界を決め、経営が育成の時間を確保し、人事が肩書きではなく会話で見極める——この順番が守れれば、資格や専門学校に振り回されることは減るはずだ。 あなたの会社では、DXの地図はもう描けているだろうか。まだなら、求人票を書く前に、登り釜の前に立つ時間から始めても遅くないと思う。
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はその枠の中で考えてくれる。毎回ゼロから指示を考えるより、型を再利用したほうが、選ぶ時間に集中できる——私はそう考えている。
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で回す」前提が固まっている人だけだと思う。
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 をサブにしている人も、まずは「作法をスキル化して渡す」発想を試す価値はあると思います。