エンジニアの思考録

仕事を受けるならブログ・X・note・LINE・GitHubをどう使い分けるべき?

AI時代に会社依存の働き方を抜け、個人で仕事を受け始めようとすると、まず最初に詰まるのが「どこに何を書けばいいのか」という媒体選びの問題です。Xを伸ばせばよい、noteで記事を売ればよい、LINEを作れば顧客がつく、ブログを書けば検索から仕事が来る。こうした断片的な助言が同時に飛んでくるのに、自分の手元では更新が止まり、フォロワー数だけが少しずつ動いていく状態になりがちです。

問題は、これらの媒体を「どれが正解か」という二者択一で考えてしまうことにあります。媒体には役割があります。発見される場所、信頼が積み上がる場所、相談を受ける場所、技術的な信用を見せる場所。1つの媒体ですべてを成立させようとすると、本拠地の更新が止まり、補強のために増やしたはずのSNSがいつのまにか主戦場になり、規約変更で一晩で導線が消える、という二次被害が連鎖します。

この記事では、AI時代に個人で仕事を受け続けるための媒体構造を、ハブ&スポークという1つの設計思想で整理します。本拠地は自前ドメインのブログまたはホームページに置く。補強はX・GitHub・LINE公式の3点に絞る。発見 → 信頼形成 → 相談 → 仕様整理 の流れを崩さない。フォロワー数ではなく問い合わせ単価をKPIに置く。これらを順に説明していきます。

前提として、この記事は「SNSで簡単に仕事が取れる」という煽りや、特定媒体の成功者ノウハウを解説するものではありません。前記事 AI時代に個人開発で自立できるのか?作れるものと売れるものの違い で扱った「作れるもの」と「売れるもの」の違いを踏まえ、売れるものを売るための導線をどう設計するかという、より実務的な層を扱います。

読み終えたとき、自分の媒体運用について「どこを本拠地にし、どこを補強にし、どこから相談を受け、どこを切り捨てるか」の判断軸が手元に残るはずです。媒体を増やす方向ではなく、減らして役割を分ける方向の地図を渡します。

AI時代に個人で仕事を受けるには「媒体の役割分担」が前提

SNSだけで仕事が取れる、ブログだけで自動受注が成立する、という前提は技術受注領域では崩れています。個人で仕事を受けるには「発見・信頼形成・相談・仕様整理」を媒体ごとに分け、本拠地と補強の役割を整理する必要があります。本章では、なぜ媒体の役割分担が前提になるのかを、SNS単独依存の限界とハブ&スポーク構造の視点から整理します。

図 1: 本拠地(ブログ/ホームページ)を中心に、X・GitHub・LINE公式が役割別に補強として配置される媒体役割分担の全体像

SNSだけで仕事が取れる前提が崩れた背景

X API有料化・LINE公式の料金改定・Facebookオーガニックリーチ低下といった変動が連続する2023〜2026年の文脈で、SNS単独で個人受注を継続する前提は弱くなっています。フォロワー数が増えても受注単価・成約率が変わらない構造的失敗が、複数の業界調査で繰り返し指摘されています。

X APIは2023-02に有料化のアナウンスがあり、その後Basicプランの値上げが2024-11にも行われました。LINE公式アカウントは2023-06に料金改定が入り、無料枠が月200通、ライトプランが5,000通、スタンダードプランが30,000通という構造に変わっています。Facebookのオーガニックリーチは長期的に低下傾向で、ページ投稿が自然に届く割合は1〜3%まで落ち込んでいると複数の業界調査が示しています。

つまり、SNSの集客力は所有者の方針変更ひとつで一晩のうちに条件が変わる構造を持っています。SNS単独で受注導線を組むと、自分の責任範囲外の変動に直接事業をさらすことになります。

「発見・信頼形成・相談・仕様整理」を分ける視点

媒体は「発見される場所」「信頼を積む場所」「相談を受ける場所」「技術的信用を見せる場所」の4つに分解できます。1媒体ですべてを成立させようとすると、本拠地の更新が止まる二次的消耗が発生します。

発見は短い投稿で広く届く媒体が向きます。信頼形成は長文の判断軸が積み上がる媒体が向きます。相談は1対1のクローズドな経路が向きます。技術的信用はコードという物証を見せる媒体が向きます。これらを1つの媒体に押し込めると、長文を書く時間がSNS運用に取られ、相談導線が公開タイムラインに紛れ、技術記事の品質が短文SNSの粒度まで引きずられます。

媒体ごとに役割を割り当てて、他の役割はその媒体に背負わせない、という線引きが媒体運用の基本になります。

ハブ&スポーク構造で本拠地と補強を整理する

本拠地(ハブ)を1つに固定し、補強媒体(スポーク)を目的別に配置する設計を採用します。スポーク同士を横でつなげず、すべてハブを経由させる構造で、規約変更や所有者方針変更が起きてもハブが残る形にします。

この構造の利点は、補強媒体の1つが消えても本拠地が残ること、補強媒体間の運用方針を媒体ごとに独立させられること、相談導線を本拠地経由に固定できることの3つです。Xでバズった読者を直接LINE公式に流すのではなく、いったん本拠地のブログ記事に着地させてから相談導線へ送る、というワンクッションを入れることで、媒体依存リスクを最小化します。

本拠地は自前ドメインのブログまたはホームページに置く

個人で仕事を受ける本拠地は、自前ドメインのブログまたはホームページに置きます。検索資産化・LP配置・問い合わせ導線・移転自由度の4つを唯一同時に満たす媒体だからです。本章では、本拠地を自前ドメインに置く構造的な理由と、ブログとホームページの役割の違い、立ち上げ初期のリアルな制約を扱います。

図 2: 検索資産化・LP配置・問い合わせ導線・移転自由度の4要素を、自前ドメインのブログ/ホームページのみが同時に満たすことを示す比較マトリクス

ブログとホームページが「唯一」4つを同時に満たす構造

自前ドメインのブログとホームページだけが、検索資産・問い合わせ自由度・LP自由度・移転自由度を同時に成立させます。SNSやnoteはこの4つのいずれかが構造的に欠けます。

検索資産化とは、過去に書いた記事が時間とともに検索流入を積み上げ続ける性質を指します。SNSのタイムラインは数日でほぼ閲覧されなくなる流動的な構造のため、検索資産にはなりません。問い合わせ自由度は、フォーム・メールリンク・LINE公式への導線・電話番号など、自分の判断で配置できる自由度を指します。SNSは1つのプロフィール欄しか自由に使えず、ホームページのような複数導線設計はできません。

LP自由度は、サービス紹介・実績紹介・料金表・問い合わせフォームを、見せたい順序で見せたい粒度で配置できる自由度です。noteでは記事ページの構造がプラットフォーム側に固定されており、独自LPは作れません。移転自由度は、媒体の所有者方針が変わったときに別環境に移しても資産を持ち越せる自由度です。SNSやnoteの記事はそれぞれの媒体に紐づいており、独自ドメインへ移して同じSEO評価を引き継ぐことはできません。

この4要素を同時に満たせるのは、自前ドメイン上のブログとホームページのみです。

ブログとホームページの役割の違い

ブログは検索流入と思考の蓄積・実績の記事化に向き、ホームページはサービス説明・問い合わせ・実績・プロフィールを固定して見せる場所として分けます。同じ自前ドメイン上で2つを並行運用するのが現実解です。

ブログは時系列で増える流動的なコンテンツ、ホームページは更新頻度の低い固定的なコンテンツとして役割を分けます。ブログ記事の末尾からホームページの問い合わせフォームに送る、ホームページの実績欄からブログの該当記事に送る、という相互導線を組むことで、本拠地内で発見 → 信頼形成 → 相談 の流れを完結させられます。

WordPressと固定ページの組み合わせ、あるいはNext.js + 静的生成 + 別パスのホームページ構成など、実装方法は問いません。重要なのは「同じ自前ドメイン上に2種類のコンテンツが同居している」状態を作ることです。

立ち上げ初期に本拠地ブログ単独では到達しない問題

検索資産化は半年〜1年単位の長期投資のため、立ち上げ初期はSNSやGitHubの補強がないと読者に到達しません。「本拠地ブログだけで完結する」前提で運用を始めると、流入が積み上がる前に止まります。

Google検索からの自然流入が安定するまでには、記事数・ドメイン年齢・被リンク・サイト構造などの複合要因が必要で、書き始めてすぐ流入が立ち上がる媒体ではありません。一方で、Xや GitHub のプロフィールREADMEは、書いた当日から読者の目に触れる経路を持ちます。

つまり、本拠地ブログを長期資産として積み上げる前提に、SNSや GitHub などの即時到達経路を補強として並走させる構造が、立ち上げ初期から半年〜1年の橋渡しに必要になります。本拠地は本拠地として作りつつ、その期間の到達手段を補強媒体に持たせる、という分業がハブ&スポーク構造の実装側の意味です。

SNS・noteを本拠地にしてはいけない構造的理由

X・Instagram・FacebookなどのSNSや、noteを本拠地に置くと、規約変更・所有者方針変更・SEO評価の帰属先という構造的要因で集客が一晩で消えうるリスクを抱えます。本章では、各媒体ごとの構造的限界とフォロワーゲームの罠を順に整理します。

SNSの規約・アルゴリズム変動で集客が一晩で消えうる

X API有料化(2023-02アナウンス、Basic値上げ2024-11)・LINE公式の2023-06料金改定(無料200通/ライト5,000通/スタンダード30,000通)・Facebookオーガニックリーチ低下といった変動が連続して観察されています。所有者の方針変更で集客導線が一晩で変わりうる構造です。

ここで重要なのは、これらの変動が事業判断とは無関係に外部から押し付けられる点です。X APIの利用条件、LINE公式の月額料金枠、Facebookのアルゴリズム重み付け、いずれも個人事業主側に交渉余地はなく、変更されたら受け入れる以外の選択肢はありません。SNSを本拠地にするとは、こうした外部変動の影響を直接受ける位置に事業基盤を置くことを意味します。

AIによる検索流入の構造変化についても、媒体側の影響評価とは別に、検索流入そのものが減りうる時代背景があります。詳細は AI情報時代における個人ブログの価値・未来 ― 声が届かない死の世界 で扱っていますが、SNSと検索の両方が同時に揺れるなかで、本拠地を所有者方針に依存しない自前ドメインに置くことの意味は、以前より重くなっています。

noteは独自ドメイン移転不可・SEO評価がnoteに帰属する

noteはnote.comの共有ドメイン上に記事が置かれ、独自ドメインへの移転は構造的にできません。SEO評価はnoteドメインに帰属し、自前ドメインでの資産化はできません。note proは月額80,000円(税抜)の別契約です。

note上で書いた記事のSEO評価は、note.comドメイン全体に紐づく形で蓄積されます。仮に将来note上の運営方針が変わっても、自分の記事を独自ドメインに引き上げて同じ検索順位を維持することはできません。記事のテキストはエクスポートできても、SEO上の資産は持ち出せない、という構造的制約があります。

note proを契約すると独自ドメインの設定はできますが、月額80,000円(税抜)というコスト水準は個人受注の本拠地としては割高で、同じコストでWordPress + レンタルサーバーや静的サイトホスティングを組む方が、自由度・所有権・移転自由度のいずれでも有利です。

Instagram・Facebookは技術受注の主軸にしにくい

Instagramはビジュアル中心で技術判断材料を探しに来る層が薄く、Facebookはオーガニックリーチが1〜3%まで低下し30代以下利用率も低水準です。ビジュアル業種・既存人脈用途以外では、技術受注の主軸にはしにくい媒体です。

Instagramは画像・動画を中心とした媒体設計で、技術判断軸の長文や仕様整理ノウハウを伝えるには粒度が合いません。デザイン・建築・飲食などビジュアルが意思決定に直結する業種では機能しますが、業務システム・自動化・受託開発のような技術受注では、伝えたい情報密度に対して媒体が薄すぎます。

Facebookはオーガニックリーチの低下と利用層の高齢化で、新規発見媒体としての役割は薄れています。既存人脈の維持や、特定地域コミュニティ向けの告知用途では使えますが、見知らぬ見込み顧客に発見されるための補強媒体としては優先度が下がります。

フォロワー数を目的化するとフォロワーゲームになる

フォロワー獲得条件と受注発生条件はずれており、フォロワー数を集客KPIに置くと低単価層を多く含むトラフィックを集めて消耗します。フォロワー数と受注単価・成約率は別軸である事実が複数の業界調査で繰り返し指摘されています。

フォロワーが増えやすい投稿は、ノウハウ無料公開・煽りトーン・トレンド便乗・極端な意見表明などで、いずれも「読みやすく、共感されやすく、保存されやすい」性質を持ちます。一方、受注が発生しやすい投稿は、判断軸の整理・実装の落とし穴・コスト構造の分解など、読者が自分の業務に重ねられる粒度を持つ投稿です。

両者は重なる部分もありますが、フォロワーを増やすことを主目的に置くと、受注に結びつかない読者層が増えていく傾向があります。フォロワー1万人で問い合わせゼロ、という状態は珍しくありません。媒体KPIをフォロワー数に置く運用は、この構造的なズレを見落としやすい設計です。

補強媒体3点(X・GitHub・LINE公式)の役割を分ける

補強媒体は優先度順にX・GitHub・LINE公式の3点に絞ります。それ以上を同時運用すると、本拠地ブログの更新が止まる二次的消耗が発生します。本章では、3媒体の役割と「他で代替させない」境界を整理します。

図 3: 本拠地ブログ/ホームページをハブとし、X(発見)・GitHub(技術的信用)・LINE公式(相談クロージング)の3スポークが役割を分けて配置されるハブ&スポーク構造

Xは「発見・瞬発拡散」専用(外部リンク抑制は時点付きで扱う)

Xは記事公開時の瞬発拡散と直接DMでの相談接触に機能を絞り、本拠地化はしません。外部リンク抑制は2024-11のMusk発言と2025-10のX側否定で発言が分かれており、現時点でも継続中とは断定しません。

Xの強みは投稿後数時間〜1日のうちに広く届く瞬発拡散と、DMによる1対1接触の容易さです。一方で、過去の投稿が検索資産として積み上がる構造は弱く、長文の判断軸を恒常的に届ける媒体としては不向きです。本拠地のブログ記事を公開したタイミングで告知に使う、相談DMの最初の接触経路として開けておく、という補強用途に役割を絞ります。

外部リンクのリーチについては、2024-11にMuskが「外部リンクは抑制する」と発言した一方、2025-10にX社側が抑制継続を否定する発言も出ており、時点による発言のずれがあります。本記事執筆時点では「現在も抑制中」と断定せず、リンクをリプライ側に置く運用パターンが媒体運用界で広く採用されている事実だけを参照します。

GitHubは「技術的信用の物証」専用

GitHubはプロフィールREADMEとショーケースリポジトリ最大6件で「コードという物証」を提示する補強媒体として位置づけます。仕様整理・自動化・Shell作成支援のサンプルコードや指示文を置きやすく、本拠地ブログとLINE公式への導線を貼ることで価値が最大化します。

GitHubのプロフィールページにはピン留めリポジトリを最大6件まで表示でき、プロフィールREADMEで自己紹介・スキル・連絡先・本拠地ブログへの導線を固定的に見せられます。技術受注の判断材料として「動くコードがあるか」「コードの粒度が荒くないか」「直近にコミットがあるか」を見られる場面が増えており、GitHubのアカウントが事実上のポートフォリオとして機能します。

セットアップ手順・README構成・ピン留め選定の実装側は GitHubの使い方を完全解説|アカウント作成から実践活用までを紹介 で扱っています。本記事では「補強媒体の役割としてどこに置くか」までを扱い、実装手順は関連記事側へ送ります。

注意点として、GitHubに直接相談DMを受け取る経路は標準では用意されていません。GitHubで信用を積んだ後、本拠地ブログまたはLINE公式へ送る導線を必ずプロフィールREADMEに含めることが、補強媒体としての設計上の必須条件です。

LINE公式は「相談クロージング」専用

LINE公式は1:1チャット・リッチメニュー・ステップ配信で、ブログで信頼形成された層を相談クロージングに変換する媒体として配置します。月200通の無料枠で個人受注規模なら十分機能しますが、配信量増でコスト急増リスクがあるため拡大時はメール配信併用を検討します。

LINE公式の強みは、フォーム送信よりも心理的ハードルが低い1対1チャット導線と、リッチメニューで「相談する」「料金を見る」「事例を見る」など複数アクションを並列で見せられる構造です。ブログ記事末尾から「もう少し詳しく聞きたい場合はLINEで」という形で送り込むと、フォーム以外の相談接触経路が用意できます。

料金は2023-06の改定後、無料プランで月200通まで、ライトプランで月5,000通まで、スタンダードプランで月30,000通までという配信通数の枠が設定されています。個人受注規模なら無料枠で十分機能することが多い一方、登録者数が増えて配信量が拡大すると、プランを上げる必要が出る可能性があります。配信規模の拡大局面では、LINE公式の役割を「相談クロージング」に絞ったまま、一斉配信のメッセージはメール配信に寄せる、という分業も検討対象です。

補強媒体を3点に絞る理由

補強媒体を増やしすぎると、本拠地ブログの更新時間が削られ、各媒体の品質も均等に薄まります。本記事では補強媒体をX・GitHub・LINE公式の3点に絞り、Instagram・Facebook・YouTube・TikTokなどは原則として補強の主軸に入れません。

3点に絞る理由は、それぞれの役割が「発見」「技術的信用」「相談クロージング」と重複しない設計になっているからです。Instagramを加えるとX(発見)と機能が一部重なり、運用工数の割に増加分の効用が小さくなります。YouTubeは派生媒体として価値はあるものの、撮影・編集の工数が重く、本拠地ブログの更新を止める誘因になりやすい媒体です。

3点に絞ったうえで、本拠地ブログの更新を止めない範囲で運用するのが、個人受注規模での現実的な配分です。

「発見 → 信頼形成 → 相談 → 仕様整理」の流れを崩さないハブ&スポーク

媒体を増やすことではなく、発見 → 信頼形成 → 相談 → 仕様整理 の4段階の流れを崩さないことが本筋です。本章では、記事公開時のシーケンス・KPIの置き方・プラットフォーム依存リスクの最小化を、運用レベルに降ろして整理します。

図 4: 発見(X) → 信頼形成(本拠地ブログ) → 相談(LINE公式/フォーム) → 仕様整理(個別やり取り)の4段階フローと、各段階に対応する媒体の配置

記事公開時のシーケンスを固定する

ブログ公開 → X告知(リンクはリプライ側) → GitHub README更新 → LINE公式で必要時配信、の固定シーケンスで運用します。媒体ごとに「本拠地に送る経路」を1つは必ず持つことが、ハブ&スポーク構造の最小条件です。

記事を本拠地ブログに公開したら、Xで告知投稿を出します。本文側には記事の要約だけを書き、リンクはリプライ側に置く運用を多くの媒体運用者が採用しています。GitHub のプロフィールREADMEには直近書いた記事3〜5件のリンクを表示し、新しい記事を上に積む形で更新します。LINE公式は登録者がいる前提で、配信量を月200通の無料枠に収まるよう「重要な記事のみ」配信に絞ります。

このシーケンスを固定することで、1記事あたりの公開作業が約30〜45分の定型作業になり、運用コストが予測可能になります。媒体ごとに告知タイミングや内容を毎回考えると、運用が重くなって本拠地の更新が止まる原因になります。

媒体KPIをフォロワー数から問い合わせ単価に切り替える

フォロワー数ではなく、ブログ流入数・LINE公式登録率・問い合わせ件数・問い合わせ単価・成約率をKPIに置きます。可視化されやすい数字に意識を引きずられないことが、フォロワーゲームに転落しないための実務的な歯止めになります。

フォロワー数は媒体側のダッシュボードで毎日見える数字なので、無意識にKPIに昇格しがちです。ですが、個人受注の事業KPIとしては「何件の問い合わせが入ったか」「問い合わせ1件あたりにいくらの工数が掛かっているか」「問い合わせから成約に至った割合」のほうが、収益と直接連動します。

実務的には、月単位で「ブログ月間流入PV」「LINE公式新規登録数」「問い合わせ件数」「成約件数」「成約金額合計」の5指標を記録するだけで、フォロワー数に意識を引きずられない判断軸が得られます。媒体ごとのフォロワー数は補助指標として把握する程度にとどめ、毎月の判断材料には入れない運用が、フォロワーゲームへの転落を防ぎます。

プラットフォーム依存リスクを最小化する原則

規約変更・課金構造変更・アルゴリズム変動・所有者方針変更の4つのリスクを、本拠地を依存度最小の自前ドメインに置くことで吸収します。スポークの一つが消えても他で代替可能な構造を維持することが、5年・10年スパンでの個人受注継続を支えます。

規約変更は、過去の投稿が突然削除対象になる、利用規約に新しい禁止事項が追加される、といった形で起こります。課金構造変更は、X APIの値上げやLINE公式の料金改定のように、運用コストが急増する形で起こります。アルゴリズム変動は、Facebookオーガニックリーチ低下や Instagram のフィード優先度変更のように、リーチが急減する形で起こります。所有者方針変更は、媒体所有企業の経営判断やオーナー交代で、媒体の方向性そのものが変わる形で起こります。

このうち、本拠地を自前ドメインに置けば、どの変動が起きても本拠地は動きません。補強媒体のいずれか1つが消えても、残りの2つで橋渡しができ、本拠地が残っていれば再構築の起点が確保できます。受注後に発生するAI自動化のコスト構造についても、関連記事 n8nでAI自動化するとAPI課金が膨らむ理由:構造と用途別の月額試算 で扱っており、媒体側のコスト変動と合わせて、外部依存先を分散させる発想が個人受注継続の前提条件になります。

まとめ

個人で仕事を受けるには、SNSやnoteを本拠地にせず、自前のブログまたはホームページを本拠地にし、X・GitHub・LINE公式を役割別の補強として配置する構造が現実的です。重要なのは媒体を増やすことではなく、発見 → 信頼形成 → 相談 → 仕様整理 の流れを崩さないことです。フォロワー数や成功者の集客論ではなく、「相談される前に何を見せておくか」を設計の起点に置きます。

本記事で示したハブ&スポーク構造は、媒体を増やす方向ではなく、役割を分けて減らす方向の設計です。本拠地は1つ、補強は3点まで。それ以上を同時運用すると、本拠地の更新が止まり、補強のために増やした媒体が逆に主戦場になり、規約変更で一晩で導線が消えるという二次被害の連鎖に巻き込まれます。

KPIはフォロワー数ではなく、ブログ流入数・LINE公式登録率・問い合わせ件数・問い合わせ単価・成約率に置きます。可視化されやすい数字に意識を引きずられないことが、フォロワーゲームに転落しないための実務的な歯止めです。媒体運用は事業基盤の一部であり、媒体側の方針変更に事業を晒さないための構造設計が、5年・10年スパンでの個人受注継続を支えます。

本記事の論点を補強する関連解説記事を3点並べます。本拠地ブログの存在意義、GitHubの使い方、AI自動化のコスト構造の3方向から、本記事の前提と後段をそれぞれ補強します。

次の記事

媒体導線を決めた後の次の段階は、AI自動化を入れたときに「自分が作業者ポジションに固定されないための設計」です。シリーズ次記事で、n8nとAIエージェントの使い分けを扱います。

関連記事

よく読まれている記事

1

「私たちが日々利用しているスマートフォンやインターネット、そしてスーパーコンピュータやクラウドサービス――これらの多くがLinuxの力で動いていることをご存じですか? 無料で使えるだけでなく、高い柔軟 ...

2

Linux環境でよく目にする「Vim」という名前。サーバーにログインしたら突然Vimが開いてしまい、「どうやって入力するの?」「保存や終了ができない!」と困った経験をした人も多いのではないでしょうか。 ...

3

ネットワーク技術は現代のITインフラにおいて不可欠な要素となっています。しかし、ネットワークを深く理解するためには、その基本となる「プロトコル」と「レイヤ」の概念をしっかり把握することが重要です。 こ ...

4

この記事は、Linuxについて勉強している初心者の方向けに「Shellスクリプト」について解説します。最後まで読んで頂けましたら、Shellスクリプトはどのような役割を担っているのか?を理解出来るよう ...

5

Javaは世界中で広く使われているプログラミング言語であり、特に業務システムやWebアプリケーションの開発において欠かせない存在です。本記事では、初心者向けにJavaの基礎知識を網羅し、環境構築から基 ...

-エンジニアの思考録