Olivia
Online
Kentaro Nakano
@kcp_kn
株式会社KCP 代表取締役 | 海外AI最新動向を経営者向けに解説 | Claude Code/Codexで実際に自社で検証 | 月3万円からAI導入支援を提供中 | 同じ経営者の方フォロー・DM歓迎しております
Joined January 2022
201 Following
472 Followers
530 Posts
Pinned Tweet
「AIっぽさを無くすSEO記事作成ワークフロー」
個人開発者のMaks氏( @maks6361 )のSEO記事作成ワークフローの話。
Googleが見ているのは「AIか人間か」ではなく、役に立つか/ オリジナルか / 人のために書かれたか どうか。
①キーワードを勝手に選ばせない
記事テーマは事前に作ったキーワード一覧から選ぶ。
一覧が空なら止まる。
近いテーマをAIが勝手に選んで、公開を続ける設計にはしない。
②検索意図を先に決める
書き始める前に読者が何を求めているかを分類する。
比較、手順、定義、購入ガイド、トラブル対応、リストなど。
キーワードを何度も詰め込むのではなく、読者の意図に答えるため。
③商品情報は定義ファイルで検証する
アプリについての説明はあらかじめ用意した商品定義ファイルと照合する。
そこには「ある機能」だけでなく「ない機能」も書く。
ここが重要で、LLMは放っておくと都合よく補完してしまう。
④記事構成を固定する
タイトル、冒頭の短い回答、AIエンジン向けの長めの回答、FAQ、内部リンク、商品セクション、CTA。
SEOだけでなく、LLMに引用・参照されることも意識した構造になっている。
⑤公開前に2回、AIっぽさを削る
1回目は誇張語、企業っぽい動詞、空のマーケ文句、根拠のない主張を落とす。
2回目は同じ文言の繰り返し、弱い接続、長すぎる段落、いかにもなダッシュなどを見直す。
⑥スコアが低ければ戻す
公開前に品質スコアを付ける。
重みが大きいのは「人間が書いたように読めるか」と「商品説明が本当に正しいか」。
基準に届かなければ、構成作成の段階まで戻す。
⑦承認後だけ公開する
承認後に画像生成、サイトビルド、デプロイ、Telegram通知まで進む。
つまり、単発プロンプトではなく、品質ゲート付きの業務フローになっている。
⑧所感
弊社KCPでもBlog作成のスキルとして品質レビューなどを入れておりますが、①キーワードを勝手に選ばせない ができていなかったので、こちらもワークフローに含める予定。
事前にSEO戦略・コンテンツ管理表を作った上で、それを上から順にAIでこの執筆ワークフローを当てはめていくのがベストかなと思います。
https://t.co/v0FGOPemS9
「toBにおいて最も価値のあるAI自動化ワークフロー5選」
2026年に企業が実際に購入しているAI自動化ワークフローは「買い手需要」「導入された証拠」「明確な発注者」「測定可能な定量成果」が揃ったものに集中している。
市場調査や実際の導入事例から抽出された5大ワークフローと成約に不可欠な現場適合の手順を整理。
■ 企業が実際に導入する5大AI自動化
① リード審査とフォローアップ
流入したリード情報を自動付加し、自社ルールでスコアリングしてCRM更新や商談予約へ繋ぐ。
Siemensは週2,800件のインバウンドリードに対して約50件の検証ルールで運用している。
多数のエージェントを会話させる複雑な構造を避け、明確なルール、信頼できるCRM連携、人間への確実な引き継ぎを備えた単一システムにする。
指標：応答時間の短縮、適格リードの商談予約率
② カスタマーサポート対応解決
承認済みソースから回答を生成し、注文確認や返品可否など安全な定型処理を完結させる。
Salesforceの調査ではサービス組織でのエージェント導入率が2025年の39%から2026年には66%へ急増し、70%が60日以内に測定可能な価値を実感している。
引き継ぎ時に要約・参照元・実行済みアクション・推奨ネクストステップを渡し、サポート担当者にゼロからやり直させない設計にする。
返金や例外は人間へ引き継ぐ。
指標：無人解決チケット数、再オープン率
③ 音声AIによる不在着信回収と予約受付
営業時間外の電話を受電し、要件確認から予約確定・カレンダー更新までを自動化する。
Fiverrの調査ではAI音声エージェントの検索数が半年で49%増加した。AIである旨の開示やプライバシー規制の遵守、アクセントや割り込みに対するストレステストを実施する。
指標：回収された予約数、予約獲得単価
④ 書類から基幹システムへのデータ処理
メールやフォルダに届いた請求書などの書類を識別し、項目抽出と照合を行ってシステムへ下書きを作成する。
Microsoft事例では週40時間削減とエラー99%減を達成。Zapier調査でも企業AI用途の47%を占める最多用途である。運用初期はお金を動かす処理を自動実行せず下書き作成に留め、人間が承認する。
指標：項目抽出精度、手修正なしで承認されたドラフト率
⑤ 社員サービスとオンボーディング
内定承諾後のアクセス申請、備品手配、規程回答、未完了タスクのリマインドを自動化する。
FranklinCoveyの事例ではHR業務フローが30日から2時間へ短縮された。アカウント発行などの権限付与は管理者承認を挟む。
指標：新入社員の立ち上がり日数、タスク抜け漏れ削減数
■ AI自動化ワークフロー構築者が見落としがちな現場適合の7ステップ
自動化システム単体は製品の半分に過ぎず、残りの半分は業務プロセスへの適合にある。
1. 現場の実務担当者にインタビューする
2. ステークホルダー全員と前提を調整する
3. 理想の手順だけでなく直近の例外ケース3件を辿る
4. トリガー、システム、データ、意思決定ポイントをマップ化する
5. ルール処理とAI推論が必要な処理を分ける
6. 例外処理、人間の承認関門、成功指標を明文化する
7. 企業の既存インフラと権限構造に合わせて実装を調整する
■ 特化型ポジショニングの原則
20種類の料理を並べるファミレスよりステーキ専門店が選ばれるように、空調設備のオーナーなら緊急呼出や配車ルールを熟知した専門家を選ぶ。
「1つの買い手」「1つの業務プロセス」「1つの測定可能な成果」に絞った特化型プロジェクトを持つことが商談相手のペインを解決して信頼を獲得することができる。
https://t.co/gkVcLnwca9
GPT-5.6 SolやOpus 5とそこまで大差ない性能のMuse Spark 1.3が公開されたとマーク・ザッカーバーグ自らポスト。
現在Open Code(オープンソース版のclaude codeみたいなやつ)で無料で使えるらしいです。
Muse Spark 1.3 is rolling out today with frontier performance almost too cheap to meter. This is the biggest jump we've made so far on coding and agentic work. Try it in Muse Code and our API.
Next up 🍉 and Muse Spark open weights releases coming soon.
「Grok Botで事業仮説を選別する収益システムの設計」
Grok Botで事業の発見から検証、販売、運用までを回す設計ガイド。
意外だったのは案を大量に出す話がほとんどなく、拾った課題のほとんどを候補に上げないための線引きについて記載されていた。
前提として、この仕組みは5つの収集システムが毎日それぞれ別の情報源を読む。
1. すでに金が動いている場所：Upwork/Fiverrの継続案件、Indeedの求人、有料ツールの星1〜3レビュー
2. 経営者・実務家の発言：ポッドキャストとYouTubeの文字起こし
3. タイミング：規制変更、許認可、新規事業登録、気象
4. オーナーの不満：業界フォーラム、Reddit
5. 新規ローンチ：Product Hunt、GitHub Trending、Show HN
拾った課題は毎晩まとめて似たもの同士のクラスタにする。ここまでは機械の仕事で人間は見ない。
① 何個のシステムが裏を取ったかで採点する
クラスタごとに点をつける。
配点で最重視するのは「いくつのシステムが同じ課題を確認したか」。次に具体的な金額が付いているかどうか。
1つのシステムしか拾っていない課題は誰か1人の不満でしかない。
だからレビューだけ求人だけでは上げない。
求人が出ているなら「その業務に年4.5万ドルの人件費を払っている」証拠になるし、有料ツールへの低評価なら「月額を払ってなお直っていない」証拠になる。
すでに口座から出ている金として読み取る。
ポッドキャストの発言は単独では候補にしない。
他のシステムが見つけたものの点を上げる用途に限定している。声の大きい話題をそのまま拾ってしまうから。
② 昇格の線を先に引く
・70点以上かつ2システムの確認 → 「候補」に上げる
・85点以上かつ3システムの確認と検証済みの数字 → 初めて「作りましょう」と提案する
数字は出典URLなしでは使わせず、裏が取れないものには「未検証」と書かせる。
さらに直近30件の自分の判断（進める・観察・停止）と理由を採点に食わせて、過去に落とした型は減点する。判断が溜まるほど、自分が実際に作るものへ寄っていく。
③ ほとんどが落ちるのが正常
著者の実行例では576件を集めて72件の課題を抽出、57クラスタにまとまり、候補まで上がったのは1件だけ（空調事業者の臨時技術者確保、2システム確認、84.9点）。残り56件は観察のまま置いた。
観察に残ったほうにも決済手数料が月9,000ドル、歯科の保険請求業務に人が1日取られるといった重そうな課題は入っている。
それでも1システムしか裏がないので動かさない。
この「56件を放置できること」がこの仕組みの良いところだと思う。
④ 承認を出してもいきなり商品は作らない
最初に置くのは次の4点。
・証拠に使った本人の言葉をそのまま見出しにした販売ページ
・すでに払っている金額を基準にした価格
・その場で決済できるリンク
・撤退基準（これを下回ったら畳む数字）
待機リストへの登録では「興味がある」しか分からない。
決済画面まで進むかどうかで判定する。
⑤ 権限の境界を先に決める
・1回の承認で通す：調査、販売ページ、決済リンク、下書き、見込み客リスト（安く、戻せて、誰にも触らない）
・都度承認：対人の送信、郵送、広告出稿
・そもそもやらせない：返金、価格変更、送金
・同時稼働は最大2件。全件に撤退基準を付ける
案を承認することと500通の郵送を承認することは別の決定だから分ける。
https://t.co/7M4fTAKrwp
「ハーネスを操作するハーネス」という解説をしていたこの動画を見てやっとGrok Botの使い方が腹落ちしました。
仮想のコンピュータごと貸し出しているという体なのでイメージとしては、
・PCを持ったAIエージェントがどこでもいつでも動く
・いつでもGrok Botを通してそいつに指示できる
・各種サービスにログインすれば自分名義で操作してもらえる。
こんな感じ。
なのでAPIを使わなくても、claude codeやcodexで作った文をGrok Botが自身のPCのブラウザから扱える。
このポスト自体もそのように確認して修正してもらったものです。
Grok Bot、月$30から始められる Super Grokに常時稼働のLinuxマシンが丸ごと付いてくるのがヤバい話
Botに Tailscale 入れさせればSSHが通って 中は普通のLinuxなんで Claude Code も Codex も入る
実は僕もリリース直後からやってますww
Grok Bot は外側の指示役に置いて 実装は中のハーネスに回す形
それと同スペックのVPSを借りたら月7,000〜15,000円なんで 常時稼働のLinux機として見ても単純に安い
で
自由に使わせるほど ユーザーのユースケースがそのままxAIに集まるんですよね。そこまで考えてそうなのが強い
ハーネスがどう使われてるかっていう 一番おいしい食糧を集めにいってる
正面から戦わずに計算機を貸す側に回る これは強者ムーブ
本質から解説するのはしっかり動画でやりました👇
https://t.co/jcq4xknKoD
「Grok Botで一人会社を段階的に実装する方法」
Grok Botで一人会社の組織図を1部門ずつ埋めていくという記事。
まずGrok Botは1体ごとに専用のクラウドマシンを持つ。
実物のブラウザ、ファイルシステム、ターミナルを持ち、渡した認証情報で普段の業務ツールにサインインして、人と同じように画面を操作する。
PCを閉じても作業を続け、承認が要るときだけ戻ってくる。
xAIは公開前に社内で営業・マーケ・総務・保守のBotを回して確かめている。
ワークフローを並べる書き方だと噛み合わない自動化が5個できるだけで会社にならない。
だから著者は組織図の形にこだわる。
組織図にすると部門ごとに「これは誰の仕事か」「何をもって成功か」「誰に報告するか」を先に決めることになる。
① 4部門の役割と人間が握る部分
・営業／事業開発：対象企業の調査、購買意図の評価、相手固有の情報を入れた営業文の下書き。
最初は10〜20社の小さな束。送信は人間の承認後。
・マーケティング：チャネル別の文案、決めたカレンダーに沿った投稿準備、初期反応の確認。
ポジショニングとブランドの声は人間が持つ。
返ってくる質はモデルの性能よりブリーフの細かさで決まる。
・業務管理：予定調整、定型連絡、共有資料の更新。
権限はカレンダーとメールだけに絞る。
「念のため」の広い権限が低リスク部門を高リスク部門に変える入口になる。
・技術保守：定型のバグ修正と保守。
コードの不具合は他の変更を経て後から表に出る。
だから確認を厳しくする。新規設計は人間。
人間に残る判断。
どの市場へ行くか、どの商品に賭けるか、どの関係に時間を使うか、どのリスクを取るか。
機微な交渉と関係の維持も人が持つ部門に置いている。技術が成熟しても変わらないとしている。
② 1部門ずつ足す。6か月の実例
まず最もリスクの低い部門を1つだけ選び、1か月は全出力を確認する。
安定した場合だけ量を増やし、実績ができてから2部門目を足す。
部門ごとに失敗の仕方が違う。成功は横展開しない。
記事が挙げる一人コンサルの例。
1か月目、営業に1体。週10社、全部の下書きを確認する。出来は不安定。ブリーフを直す。
2か月目、ブリーフを直した分だけ出来が安定。週10社を30社へ。
3か月目、営業が固まったので業務管理を追加。
カレンダーとメールだけの狭い権限。作業が単純なのですぐ機能した。
4か月目、SNS投稿の準備にマーケを軽く追加。
5か月目、見込み客探し・日程調整・投稿で週10時間かかっていた作業が確認2時間未満に。
6か月目、3部門が安定したので技術保守を検討する。
③ 毎月測る3つ
・実際に減った時間。導入前に手作業で何時間かかっていたかと比べて実測する
・成果物にどれだけ手を入れたか
・その部門への信頼が増えているか、横ばいか、落ちているか
「最初が良かったのでレビューを緩めた → 入力が変わって質が落ちた → 見ていないので気づかない」を捕まえるための数字。
急に質が落ちたら、モデルの劣化より先に入力の変化を疑う。営業先に構造の違うサイトが混ざった、商品が増えた、といった変化が原因になりやすい。
https://t.co/DdLVQhiaJO
「8月版Grok Botの設計方法:」
AIボットは5体でも10体でも作れる。
しかし、担当、共有、人が止める箇所が曖昧だと仕事は速くならない。
Grok Botの運用をまとめた記事から、会社で使うなら先に置きたい4つを整理しました。
①窓口を一つにする
人間が複数のAIへ仕事を振り分けると、結局そこがボトルネックになる。
最初に依頼を受ける役を一つ置く。
その役が既存の担当を確認する。
担当へ渡し、結果を同じ会話へ戻す。
依頼者が調査役、作業役、確認役を毎回探さなくていい状態を作る。
②一つのボットに一つの定常業務を持たせる
「営業を全部やるAI」より業務を切った方が失敗箇所を見つけやすい。
受信メールの確認、空き枠の確認、下書き作成のように分ける。
成果が悪ければAIを責める前に仕事の切り方を直す。
毎週の担当を説明できないボットは実験として扱う。
③共有のためのファイルを残す
ボット同士は会話を共有しない。
共有できるのはファイル、グループメッセージ、明示的な引き継ぎ。
会社の前提、完了したこと、次の作業、成果物の置き場を分けておく。
これがないと調査役が知っていることを作業役が知らない状態が続く。
④送信・支払い・公開・削除は人が止める
自動化の価値は勝手に進ませることではない。
人の判断が必要なところまで、きちんと運ぶこと。
通知も同じで問題がないときはわざわざ通知しない。
例外だけを人へ上げるようにする。
https://t.co/QCsnhXg2jh
「AIトークンの請求額だけを半分にする4つの設計」
エージェントを業務へ入れた会社が次にぶつかるのが、成果は出ているのに毎月のトークン請求額が読めないという状態。
Google Cloudがこれをトークンエンジニアリングとして4つに整理していた。
4千トークンの枠へ文章を押し込む圧縮技術だった時代から、巨大なコンテキストと自律エージェントのループを前提にしたシステム設計へ主題が移っている。
① 履歴の間引きとコンテキストキャッシュ
複数のエージェントループは1ターンごとに会話履歴が積み上がる。
中間のツール出力をそのまま持ち回らず、過去の手順は要約して渡す。
コーディングエージェントがバグ修正でテストを10回走らせた場合、毎ターン数千行のターミナル出力を送り直すと解決済みのエラーをモデルに読み直させることになる。
ログを現在失敗している箇所だけに絞り、過去の修正を1文へ畳むと、1ステップあたり数千トークンが浮く。
旅程を10ステップで組ませて航空会社とホテルを5社比較させるなら、訪問した全ページの生HTMLではなく価格と日付だけを残す。
同じ資料やコードベースを何度も参照する処理ではコンテキストキャッシュで参照素材を一度アップロードして固定し、そこへ問い合わせる。
入力コストが最大75%下がる。
成熟したハーネス(Claude CodeやCodex、記事ではAntigravityと言及)はキャッシュを内部で処理する。
生のLLM APIやハーネス無しのローカルモデルで組むと、コストの振れ幅が大きくキャッシュミスも読めない。
② 即答の要らない処理をバッチへ回す
問い合わせチケット数百件の要約、週次レポートの生成、評価用データセットの採点に1秒未満の応答は要らない。
まとめて非同期で流すと一律50%割引になる。
週内に届くベンダー請求書のデータ抽出も同じ。
営業時間中の即答は要らないので、PDFを深夜のスケジュールバッチへ集約すれば、誰の作業速度も落とさずに処理費が半分になる。
③ 思考トークンに予算を置く
推論モデルは回答を返す前に内部で思考トークンを動的に生成する。
複雑な数学や設計では深い推論が答えの質を上げるが、同時にコスト要因にもなる。
50トークンで済む単純な分類の質問に、制約を置かない推論モデルが3,000の思考トークンを燃やすことがある。
質問の複雑さに応じて明示的な思考予算を設定するか、単純なタスクは推論モデルの外へ振り分ける。
決まった手順で答えが出る処理に重い推論エンジンを当てない。
④ モデルの適正配置と継続的な評価
「現実のトークンエンジニアリングの90%は自社の大規模ワークロードを確実にこなせる効率フロンティア上で最小かつ最安のモデルを使うという原則に尽きる」
分類、データ抽出、基本的な要約のような大量処理に高価な最先端モデルは要らない。
Gemini FlashやGemmaのような軽量モデルで同等の精度が出れば、100万トークンあたり数セントまで下がる。
もう一つが継続的な評価。
軽量モデルが新しく出るたびに、自社のベンチマークへ自動評価を走らせる。
品質が数パーセント以内に収まっていれば本番へ入れ替え、エンドユーザーへの影響なしで月額の推論費を即座に下げる。
社内の利用量が増えたら、Apigee AI Gatewayのようなゲートウェイで遅延要件に応じた最安のモデルやキャッシュへ振り分け、Model Armorでプロンプトインジェクションや機密データの漏洩をモデルへ届く前に止める。
トークンエンジニアリングの正体はプロンプト、処理の流し方、振り分けの3つの層へ良い設計の習慣を積む作業だと締めている。
https://t.co/jEKjdVbKAc
a16zが11億ドル(約1700億円)の新ファンド「Machine Age Fund」を設立。
投資先はチップ、メモリ、ネットワーキング、ストレージ、そしてデータセンターやロボティクス、家庭向けAI機器まで含むAIの物理層。
ソフトウェア領域の投資家として知られる会社がハードウェアを正式な投資領域に。
・ラックあたりの計算密度はH100ラックからRubinラックへ28倍
・ラック内のネットワーキングは銅配線の限界に到達
・ラック電力は5〜10kWから100〜250kWへ移り、今後3年で1MWに達する
・データセンターの規模は数十MWから数百MWへ、一部はGW級のキャンパスへ
・電力供給は系統のみから、系統＋自家電源の併用へ
ハードウェア産業の供給側はこれまで年20〜30%の成長に慣れてきた。
需要に追いつくには三桁成長が要ると書かれている。
メインフレームからクライアントサーバー、インターネット、クラウド、モバイルと計算の世代が変わるたびに作り直しは起きてきた。
今回違うのは変化の規模と幅、そして求められる速度だという主張。
a16zに来るハードウェアの案件もここ数年でわずかな数から全体の20%超まで増えたとしている。
AIの性能の上限がAIモデルの開発から電力・冷却・配線・不動産の側へ移りつつある。
https://t.co/rohq8Li7GK
「成功するプロダクトは特別なわけではなく、型がある」
Frederick James(@_frederickjames)というモバイルアプリ開発者が自分のアプリを45日で直近28日の実収益約3,765ドルまで伸ばした「型」を公開していた。
自社のプロダクトを持つ経営者にとっても、成果を再現性のある型に分解する考え方は参考になるはず。
①App Storeページはスクリーンショットで決まる
アプリの初回接点はApp Storeのページ。
重要度順にスクリーンショット、レビュー、名前とサブタイトル、アイコンの4要素。
特にスクリーンショットはチップやスライダーなどの要素が画面から立体的に「飛び出す」見せ方が高いコンバージョンにつながるという。
レビューは無いこと自体は問題でなく、星4未満の悪い評価だけが問題になる。
名前とサブタイトルは商品訴求としては重要度が低いが、検索経由での発見のしやすさ(ASO、アプリストア内の検索最適化)には効く。
実際、大手のマッチングアプリは軒並み同じキーワード(Dating, App, Chat, Singles, People, Meet)を使い、タイトルとサブタイトルで単語を重複させていない。
②オンボーディングは12〜13画面で「気付き」と「納得」を作る
オンボーディングが果たす役割は2つ。ユーザーに「自分には課題がある」と気付かせること、そして「このアプリが解決策だ」と納得させること。
画面数は12〜13画面が目安で、増やすほど有料画面までの到達率は上がるが、そこにたどり着くユーザーの意図はより強くなるというトレードオフがある。
到達率は75%以上が目標値。
すべての画面が生き残りをかけて戦う意識で無駄を削ぎ、プロダクトそのものではなく得られる結果を売ることが最も大事だという。
③ペイウォールは社会的証明→結果→機能→価格の4層構造
ペイウォール(課金への案内画面)はページ上部の社会的証明(みんな使っている、という安心感)から始まり、プロダクトではなく得られる結果を売る大きな見出し、それを支える機能説明、そして価格提示という4層構造が高コンバージョンの型だという。
価格は大手競合に倣うのが基本で年額プランは49.99ドルを超えない方が返金リクエストが増えにくい。
ダウンロードから課金への転換率は最低3%、健全な水準で5%、優秀で10%以上が目安。
④アプリ本体は価値を届け続けることが長期の収益を作る
短期的には収益最大化だけを狙っても良いが、長期的には持続しないと著者は語る。
健康・お金・学びといった人間の根源的な欲求に応えながら、継続的な機能改善でリテンションを高めること。
そして退会防止のための引き止めオファーやエンゲージ済みユーザーへの通知設計まで、収益を細く長く伸ばす工夫が続く。
https://t.co/TiEUirHevF
「3600万インプレッションと数千人規模のユーザーをX経由で獲得した方法」
Okara( @askOkara )というプロダクトのX運用に関する解説が投稿されている。
単に「毎日投稿しましょう」ではなく、Xをプロダクトの検証装置として使っている。
①ICP(理想的な顧客プロフィール)がいる場所を選ぶ
最初に決めているのはどこで発信するか。
OkaraはICPがいて、自社に知見があるチャネルとしてX、SEO、インフルエンサーマーケティングを選んだ。
ここを外すと、投稿を頑張っても「見られるけど買われない」になりやすい。
②勝ちやすいコンテンツ型を決める
OkaraがXで選んだ型は5つ。
1. launches：ローンチ／新機能・新サービスの公開
2. educational tweets/takes：ノウハウや学びに関するツイート／考察
3. demos：デモ／実演動画・紹介
4. product announcements：プロダクトに関するお知らせ・発表
5. trending topics and hot takes：トレンドの話題／持論・独自の視点
型が分からなければ、競合で伸びているものを見る。
そのうえで複数試し、成果が出た型に寄せていく。
③ローンチで初速を取り、学習する
Okaraは最初のメインプロダクトローンチで1,400万ビューを取った。
そこで「強いフック付きのデモが効果的」と学び、Reddit agent、SEO agentなど、各エージェントごとの個別ローンチにも広げている。
ローンチは告知ではなく、何の見せ方が刺さるかを学ぶ場になっている。
④デモはフックを変えて何度も出す
面白いのは、同じプロダクトでも見せ方を変え続けているところ。
「Redditから最初の100ユーザーを獲得する方法」
「Googleで1位を取り、AI回答に表示される方法」
「月10,000ドルのコンテンツチームなんて雇えない」
「スタートアップのマーケティングのやり方が分からない」
成果起点、悩み起点、機能起点でフックを変え、どのメッセージが響くかを見ている。
デモは1本作って終わりではなく、顧客の悩みごとに何度も切り直すものだと思う。
⑤教育投稿でノウハウを出し切る
B2B SaaSではノウハウや学びに関するコンテンツが効くと学び、Okaraは学んだことをかなり出している。
Reddit、SEO、LLM/ChatGPT、UGCビデオ、launchビデオなど、スタートアップの成長プレイブックを公開している。
その中にOkaraを自然に差し込む。
「ノウハウを隠して問い合わせを待つ」ではなく、「ノウハウを出し切って、この人たちは分かっていると思ってもらう」。
⑥トレンドには自社の意見を出す
Product Huntは昔ほど効果的ではない。
2016年の顧客獲得プレイブックは古い。
こういう自社領域のhot takesも出している。
ニュース紹介だけではなく、市場をどう見ているかを出す。
ここで思想や判断軸が見える。
⑦学びをプロダクトへ戻す
Okaraは自社プロダクトを毎日使い、アイデア出し、トレンド把握、X/LinkedIn/SEO/Reddit向けコンテンツ作成をしている。
そして、そこで得た学びをOkaraへ戻している。
つまりX運用が、
・集客
・メッセージ検証
・プロダクト理解
・コンテンツ生成
・プロダクト改善
までつながっている。
X運用で本当に作るべきなのは、投稿リストではなく学習ループなんだと思われる。
どの顧客に、どの悩みを、どの見せ方で出すと反応があるのか。
その反応を見て、次の投稿とプロダクトを少しずつ変える。
これが回ると、SNSは単なる広報ではなく、事業開発の一部になる。
https://t.co/AlarNyJsEg
https://t.co/rhQQ6FGAuZ
「Linearはなぜ速いのか？」
Linearでイシューを更新する所要時間はわずか数ミリ秒。
一般的なWebアプリが通信待ちで300ミリ秒を要するのに対し、なぜ一瞬で処理を完了できるのか。
バンクーバーで働くエンジニアの０Dennis Brotzky氏による技術解説「How's Linear so fast?」はLinearの速度の正体を「Local-First基盤と無数の設計判断の積み重ね」として解き明かしている。
5つの仕組みが以下。
① ブラウザをDBにするLocal-First構造
従来のCRUDアプリは「クリック → 通信 → サーバーDB問い合わせ → 画面再描画」の往復で待ち時間が発生する。
Linearはこの関係を逆転させ、UIが読み書きする実体DBをブラウザ内のIndexedDBに置いている。
操作時はメモリ上のデータを同期的に更新して0ミリ秒で画面を変え、裏側の同期エンジンが差分をまとめてサーバーへ非同期送信する。
通信をユーザーから隠し、読み込み待機のスピナーを排除している。
② 初回読み込みを瞬時に見せる多層の先回り
アプリ起動時の待機感を削るため、複数段階で処理を先回りさせている。
・コード分割：初回描画に必要なJavaScriptだけを小さく配信する
・ログイン画面での事前キャッシュ：ユーザーが認証情報を入力している間にService Workerが裏で本体コードをキャッシュする
・投機的認証：ローカルの状態から認証済みと仮定して即座にUIを描画し、裏で認証の検証を走らせる
③ MobXによるセル単位の極小再描画
大量データを扱いながら滑らかさを保つため、監視対象をプロパティ単位まで細分化している。
IndexedDBのデータをMobXのObservableとして展開し、50件の課題が一括更新されても一覧全体は再描画せず、変更された50個のセルだけをピンポイントで書き換える。
④ 思考を止めないキーボードファースト設計
工学的な処理速度だけでなく、操作にかかる経路そのものを短縮している。
・最頻操作は単一キー（ステータス変更や担当者設定）
・画面移動は2文字の組み合わせ（g+iなど）
・グローバル検索（⌘K）：検索先はサーバーではなくメモリ上のオブジェクト群のため、入力遅延ゼロで候補が出る
1日何百回と繰り返すマウス移動を省き、操作時間を削り落としている。
⑤ 速度感を損なわないアニメーション規約
重いトランジションで速度感を台無しにしないための厳格なルールを敷いている。
・GPU合成プロパティ（transform, opacity）のみを動かし、レイアウト再計算が走るプロパティ（margin, width, height）は決して動かさない
・一覧画面の行要素にはトランジションを入れず即時反応させる
・表示は0秒で即座に出し、非表示時のみ0.15秒で消す非対称設計を採用する
「自動で長時間動くAIエージェントの暴走と忘却を防ぐ5つのハーネス設計」
数日から数週間に及ぶ自律タスクや複数セッションを跨ぐ運用ではエラーで止まるのではなく「徐々に性能が劣化し、誤った状態を正常と誤認して走り続ける現象」が課題である。
プロンプトの配置や非同期処理、状態管理の工夫で暴走を遮断する「5つのハーネス設計パターン」についてGoogleが紹介している。
個人的には特にキャッシュをヒットさせるためのテクニックはかなり参考になったのでぜひ。
①プレフィックス固定（Stable prefix）
発生する障害：毎ターン過去の記憶をプロンプトの先頭に注入すると、ハッシュ値が変わりキャッシュヒット率が0%になる。
設計パターン：変化速度でプロンプトを3層に分ける。
1. 完全固定層（先頭）：システム指示、ペルソナ、ツール定義（1バイトも変えない）
2. 低頻度変化層（中間）：ユーザープロファイル、利用可能なツール一覧
3. 高頻度変化層（末尾）：ステップカウンタ、動的記憶、ランタイム警告
効果：動的な記憶を末尾に逃がすだけで、2ターン目以降の95%がキャッシュから返り、プロンプトサイズも7万字から2.2万字以下へ圧縮される。
②バックグラウンド記憶抽出（Background learning）
発生する障害：回答直前にインラインで記憶抽出と保存を行うと次週まで使わない処理のために毎ターンの応答が遅延する。
設計パターン：ユーザーへ即座に応答を返し、記憶の抽出・保存はレスポンス後の別レーンで非同期実行する（Write-behind方式）。
本番運用の安全策：
1. 強参照の保持：Python asyncio等で未参照タスクがガベージコレクションに回収され、書き込みが失敗するのを防ぐ。
2. 隔離されたSibling Agent：記憶抽出専用の軽量エージェントを用意し、自身のフックを無効化して再帰処理を防ぐ。
3. スロットル制御：連続メッセージ時の無駄な処理を防ぐため、120秒の待機インターバルを設ける。
4. シャットダウン猶予：プロセス強制終了制限（5秒）より短い4秒のドレイン時間を設定し、終了時のデータ欠損を防ぐ。
③永続ワークスペース（Persistent workspace）
発生する障害：ステートレスなWebバックエンドのデプロイでインストール済みCLIツールや中間成果物が消去され、毎度ツールの再構築が発生する。
設計パターン：単発のコード実行器ではなく、ユーザー単位に紐づく長寿命の実行環境として永続化する。
開発環境（ローカル）と本番環境（管理サンドボックス）を同一の抽象化インターフェースで覆い、バックエンド更新時も再接続可能にする。
④失敗と状態のエンベロープ（Explicit failure）
発生する障害：子エージェントがタイムアウトやエラーで途中終了した際、ログの断片が親に返ると親モデルが「全テスト合格」などとハルシネーションを起こして成功と誤認する。
設計パターン：
1. 4つの終端状態の型定義：戻り値のエンベロープに明確なステータス（completed / timeout / halted / pending）を定義し、機械的に分岐させる。
2. 要約文字列の強制書き換え：途中停止時は要約を「INCOMPLETE: タイムアウトのため未完了。完了として報告してはならない」と書き換える（モデルはメタデータではなくテキスト本文を読むため）。
3. 上限設定とツールの剥奪：1イテレーション最大200ツール呼出、セッション最大50イテレーションで制限し、到達時はツールを剥奪してプレーンテキストで引き継ぎを書かせる。
⑤決定論的ガードチェーン（Guard chain）
発生する障害：危険なメタデータIPを文字列一致で防いでも、整数表記などのアクセスで突破される。
設計パターン：生文字列で比較せず、アドレスオブジェクトとしてパース・正規化してから3段階チェーンで検証する。
1. Exfiltration guard：メタデータIPなどの危険宛先を即座に遮断（セッション設定で解除不可）
2. Policy guard：宣言的ルールによるallow / ask / deny判定
3. Interactive prompt：最も高コストな人間の承認を最終段階に配置（不在時は自動でdeny）
・判定にLLMを使わず、パーサーと宣言的ルールのみで構成してマイクロ秒単位で完全監査可能にする。
https://t.co/snSeLTb8gW
「グラフエンジニアリングの設計方法」
53万行のコードを別言語の100万行超へ、AIが11日間で書き換えたBunの移行事例による解説。
手作業なら開発チームが約1年かける規模だったものの、6プラットフォーム・138万件のテストを検証ゲートとし、6,502回のコミットを積み上げてBun v1.4.0をリリース。
使ったのは普段使われている標準的なAIモデル。
1つのチャットで指示して待つ「直列」から、グラフ（DAG）への「並列配線」に変えたことで並列実行を成立させた。
多くの人がエージェントを動かすとき、入力して待ち、返答を手直しして次の指示を出す直列の会話を繰り返す。
結果としてコンテキストが溢れ、数手前の指示を忘れ、複数のチャット画面を開いたまま一日が終わる。
この直列の詰まりを解消するのが「グラフエンジニアリング」。基本は3つの概念だけ。
・ノード（Node）：1つの作業単位（1エージェント、1入力、1出力）。状態は共有しない
・エッジ（Edge）：依存関係（前ノードの出力が次ノードの入力になる線）
・グラフ（Graph）：独立したノードが同時に走るネットワーク
1957年のポラリスミサイル開発、1976年のmake並列ビルド、2004年のMapReduce、2014年のAirflowと同じDAG（有向グラフ）の構造。
手順は大きく5段階に整理できる。
①偽の依存関係を削る
「Aをして、次にBをする」という手順のうち、BがAの出力を本当に読んでいるか確認する。
「ファイルを要約して、次に天気を調べる」場合、天気は要約を読む必要はない。
無関係な直列接続をほどき、並列に並べ替える。
②クリティカルパスを見極める
エッジでつながる最長チェーンがチェーンが全体の最速完了時間を決める。
速度を上げたいときはエージェントを増やす前に不要な依存関係を切る。
③4フェーズで走らせる
範囲定義（Scope）→並列展開（Fan-out）→検証（Verify）→統合報告（Synthesize）の順で回す。
中間結果はチャット履歴に流し込まず、スクリプト側の変数に保持してコンテキストの消費を抑える。
④検証者を真っ新なコンテキストで分離する
作成したエージェント自身にレビューさせると自己採点バイアスで評価が甘くなる。
研究（Panickssery NeurIPS 2024）ではGPT-4は73.5%の確率で自身の生成文を認識し、10%甘く採点することが示されてる。
Claudeも自作テキストを25%甘く採点する。
検証者は別コンテキストの独立エージェントにし、テスト通過などの客観シグナルで判定させる。
⑤作業領域をGit Worktreeで分ける
同一ディレクトリで複数エージェントを並列に走らせるとファイルの書き換え競合が起きる。
stashやresetを禁止し、特定ファイルのみコミットする規約を固定した上で、Git Worktreeで作業領域を物理的に分割する。
あらかじめ計算しておくべきなのが「アムダールの法則」による速度向上の限界。
並列化率95%のタスクに16体のエージェントを投入しても、速度向上は単純計算の16倍ではなく9.14倍にとどまる。
最終統合や検証といった直列処理が全体の加速上限を縛ってしまうことが理由。
何体投入できるかではなく、直列部分をどこまで減らせるかで処理の速度が決まってくる。
a new kind of engineer is showing up. they don't write prompts, they design how the AI works. it's called graph engineering, and the people who get it now are about to make everyone else look slow https://t.co/z1HhE6voRu
「AIエージェントを使った自動営業システムの構築方法」
海外の記事で紹介されていた「自動営業システム」の設計が興味深いです。
以前話題になったプログラミングの経験がほぼない状態から、生成AIツールを使って地元の店舗や企業のWebサイトを勝手に作り、それを企業オーナーに送りつける営業手法で、短期間に月1万ドル〜数万ドル（日本円で月数百万円〜年商数千万円規模）を稼ぎ出したというエピソードがありましたが、
これを具体的にどうやるかが記載されている記事になるので、かなり活かせる内容だと思います。
①業種を10個に絞る
購入前に検索され、1件の仕事が数千ドル規模でサイト不足が受注機会の損失につながる業種を選ぶ。
②事業者を集めて採点する
Google Mapsや新規登録情報から候補を集め、サイトの有無、スマホ対応、最終更新、営業時間、口コミ、問い合わせフォームを確認する。
「この会社のサイトにある最大の問題」を1行で記録する。
③先にサイトを作る
業種ごとのテンプレートを用意し、会社情報を`data.json`へ流し込む。
毎回ゼロから制作せず、データ差し替えで一定品質のサイトを作る。
④課題を示して連絡する
問い合わせフォームがあれば、採点で見つけた問題と完成サイトのリンクを送る。
フォームがなければ、完成サイトを見せるハガキを作る。
ここで大事なのは抽象的な「サイトを作れます」ではなく、相手の会社用に動くものを見せること。
⑤決済後の運用を月額化する
顧客は管理画面へログインせず、メールで「料金を変えたい」「対応地域を増やしたい」「写真を追加したい」と依頼する。
エージェントは依頼をデータ変更へ変換し、再ビルドして公開する。
さらに口コミ獲得を追加サービスにする。
記事の価格例はサイト月額200ドル、口コミサービス月額99〜199ドル、セットで月額250ドル。テンプレートと静的サイトを使い、顧客ごとの運用原価を下げる設計。
Finder、採点、制作、接触、決済、更新、口コミ、API化、定期実行までを一つのループにする。
ただし、フォーム送信や郵送まで完全自動にしない。承認待ちのキューを置き、人間が成果物を確認してから外部へ出す。
https://t.co/7qZ5Wp697A
SuperGrokとCursor ProでもGrok Botが使えるようになったとのこと。
わずか$20プランでGrok Botを使用可能に。
All SuperGrok and Cursor Pro subscribers now have access to Grok Bot.
We're also resetting weekly usage limits for all users.
Enjoy!
「勝つ方法はまだ数多くある」
Obsidian CEOのSteph Ango（@kepano）がまとめた「競争に勝ち、堀を築くための80の戦略ベクトル」が小バズりしておりました。
生物、プロダクト、組織、ネットワークのすべてにおいて、全方位で勝てる存在はない。
突出した成果を出すプロダクトや組織はごく狭い戦略セットや珍しい組み合わせに強みを集中させてるとのこと。
元記事では80の戦略ベクトルが13領域に整理されています。自社でも活かせそうおな代表例をまとめました。
① 蓄積
・ユーザー規模：クリティカルマスに達したユーザー群によるネットワーク効果（例: 電話、インターネット、スケールしたSNS）。
・完全性：1つですべてが完結する利便性（十徳ナイフ、ウォルマート）
・自己複製：同一コピーの展開による拡大（フランチャイズ、ポプラ林）
② 時間
・職人技：時間と精緻さの投入（ライカ、手作り時計）
・有機的成長：人為的に加速できない自然な熟成（樹木、熟成チーズ）
・持久力：超長期にわたる連続稼働（原子力潜水艦、マラソン）
③ 独自性
・ニッチ特化：狭い領域での深い専門性（専門学校、パンダ）
・ハイブリッド：通常共存しない2つの強みの融合（水陸両用車、カエル）
・秘密保持：外部から解明できない独自ノウハウ（コカ・コーラの原液、手品）
④ 防御
・信頼性：保守コストと停止の最小化（トヨタ車、Zippo）
・再現性：ブレのない一貫した体験（スターバックス、ディズニー）
・反脆弱性：負荷やストレスで強靭化（BitTorrent、筋肉）
⑤ 速度と規模
・高速反復：改善サイクルの極限短縮（SpaceX）
・構成可能性：部品の自由な組み合わせ（Stripe、API）
・モジュール性：独立ユニットの組換（レゴブロック、プレハブ）
⑥ 容易さ
・直感性：説明不要の使いやすさ（ディーター・ラムスのデザイン）
・低摩擦：利用抵抗の極小化（1クリック注文）
・単純さ：故障箇所のないミニマル設計（ハンマー、無印良品）
⑦ 所感
こちらを参考に自社が「どの2〜3個のベクトルを掛け合わせて独自の立ち位置を作るか」を明確にするのがよさそうです。
例えばObsidian自体も「プライバシー(ローカル) × プラグイン拡張性(構成可能性)× ローカル保存の職人技」という特異な掛け合わせで熱狂的な支持を集めています。
自社の強みやサービス設計を棚卸しする際にとても実用的なフレームワークだと思いました。
The idea that there are no moats left is greatly exaggerated. Here are 80 ways things win in biology and business. https://t.co/ciKubFvBK8
「これからの顧客は人間ではなくエージェントになる」
Brian Roemmele（@BrianRoemmele）がCEOをAIが務め全業務をエージェントが回す「人間ゼロ企業（Zero-Human Company）」の更なるを運用メモを出していた。
彼の主張からおさえるべき3つを抜き出すと、
①新しい顧客はエージェント
AIエージェントが購買を代行し、標準化された窓口（MCP＝Model Context Protocol）経由でだけ取引する世界が来る、という話。
仕入れや相見積もりをエージェントが自動で回すなら、その窓口を持たない会社は「検索結果に出ない」どころか、そもそも候補にすら入らない。
人間向けのサイトとは別に、機械が読める窓口を用意できているかが分かれ目になる。
②唯一残る強豪優位性は「記憶 × 流通」
届ける力だけではもう守れない。
顧客のこれまでの経緯を覚えていて、次を先回りできる仕組みが乗り換えを止める。
彼は乗り換えコストが「銀行口座の移し替え並みに重くなる」と言っていて、これは自社の顧客データをどう蓄積し続けるかの話だと思う。
③人間の価値は「関係性」に寄る
取引的な作業がエージェントに移るほど、逆に本物の対面・共感・交渉ができる人間が高く評価される、という指摘。
事務作業の速さで差別化するのではなく、人が向き合う場所を意図的に残す。ここは中小企業ほど元々強い領域のはず。
「知性は安く、届ける力は高い（Intelligence Cheap, Distribution Expensive）」。
AIそのものの性能はどんどん安くなる。
だから勝負どころは性能ではなく、機械が取引できる窓口・積み上げた顧客の記憶・人にしかできない関係の3つに移っていくということ。
全部を今日やる必要はないけれども、どれも早く始めた分だけ差が開く種類のものだと感じている。
https://t.co/Z4Z7dDICoZ
Last Seen Users on Sotwe
Most Popular Users
Elon Musk
@elonmusk
241.6M followers
Barack Obama
@barackobama
119M followers
Cristiano Ronaldo
@cristiano
114.1M followers
Donald J. Trump
@realdonaldtrump
111.8M followers
Narendra Modi
@narendramodi
107.2M followers
Rihanna
@rihanna
98.7M followers
NASA
@nasa
92.4M followers
Justin Bieber
@justinbieber
91.8M followers
KATY PERRY
@katyperry
89.8M followers
Taylor Swift
@taylorswift13
83.8M followers
Lady Gaga
@ladygaga
75.2M followers
Virat Kohli
@imvkohli
73M followers
Kim Kardashian
@kimkardashian
70.8M followers
YouTube
@youtube
68.8M followers
Neymar Jr
@neymarjr
66M followers
Bill Gates
@billgates
65M followers
Selena Gomez
@selenagomez
62.9M followers
The Ellen Show
@theellenshow
62.3M followers
CNN
@cnn
61.8M followers
X
@x
60.7M followers