【Vibe Coder必修】非エンジニアがGitHub習得で挫折しない唯一の方法：自然言語だけで完結！Manus×GitHubで実現する「失敗できる開発」の方法
こんにちは！テツメモです。
AIにVibe CodingでWebサイトやアプリを作らせている時、ふと背筋が凍る瞬間がありませんか？
「よし、完璧なプロンプトができた！」
そう確信してAIに指示を投げた数秒後、画面に表示されたのは、美しかったはずのレイアウトが崩れ落ち、まるでパズルのピースをぶちまけたかのような、無残な姿…。
ほんの少しデザインを調整したかっただけなのに
たった一行、プロンプトを修正しただけなのに
積み上げてきたものが一瞬で瓦礫の山と化すあの感覚…
それはまるで、セーブポイントのない高難易度のアクションゲームをプレイしているかのようです。
一度ミスをすれば、即ゲームオーバー。
コンティニューはできず、また最初からやり直すしかない。あの絶望的な徒労感と、「またクレジットが無駄になった…」という静かな痛み。AIを使いこなそうとすればするほど、私たちはこの見えない恐怖と隣り合わせで戦わなければなりませんでした。
AIにサイトを壊された経験はありませんか？ - 完璧な指示を出し続けないと壊れてしまう恐怖
これまで、AIでVibe Codingをする行為は、常に薄氷の上を歩くようなものでした。
非エンジニアである私たちは、プログラミングという武器を持たない代わりに、「プロンプト」という魔法の呪文を駆使してAIと対話します。しかし、その呪文はあまりにも繊細で、少しでも詠唱を間違えれば、意図しない結果を招いてしまう諸刃の剣でもありました。
- 「ヘッダーのロゴを少しだけ右に…」と頼んだら、サイト全体の要素が右に寄ってしまった。
- 「この部分の色を青に変えて」と指示したら、関係ない部分まで真っ青になった。
- 良かれと思って追加した一文が、AIの誤解を招き、全てのデザインがリセットされてしまった。
こんな経験、一度や二度ではないはずです。
そのたびに私たちは、ブラウザの「戻る」ボタンが機能しないことに絶望し、AIのチャット履歴を遡っては、かろうじて正常だった頃のプロンプトを探し出す。そんな不毛な時間と精神のすり減らしを繰り返してきました。
完璧な指示を、常に、一字一句間違えることなく出し続けなければならない。このプレッシャーが、私たちの自由な発想や「ちょっと試してみよう」という創造性の芽を、静かに摘み取っていたのです。
その絶望はあなたのせいじゃない - AI開発の構造的な問題点
しかし、断言します。その絶望は、あなたのスキル不足が原因ではありません。
あなたがどれだけ優れたプロンプトエンジニアリングの知識を持っていたとしても、この問題は構造的に起こりうることなのです。なぜなら、従来のAIとの対話には、開発の世界では当たり前である「セーブ」と「ロード」の概念が決定的に欠けていたからです。
エンジニアたちが当たり前のように使っている「バージョン管理」という仕組み。それは、ゲームでいうところの「セーブポイント」を作る行為に他なりません。彼らは何か新しい変更を加える前には必ずセーブポイントを作り、もし問題が起きても、ボタン一つで安全な場所まで戻ることができるのです。
私たち非エンジニアは、そんな安全装置なしで、AIというあまりにも強力なパートナーと向き合わなければなりませんでした。それは、命綱なしでロッククライミングに挑むようなもの。どんなに熟練したクライマーでも、たった一度の気の緩みが命取りになります。
問題は、あなたにあったのではありません。私たちの戦い方、そのプロセス自体に、構造的な欠陥があったのです。
この記事が約束すること - 壊しても戻せる「安心感」と「自由」を手に入れる
もし、あなたのAI開発に「セーブポイント」を自由に設置できるとしたら、どうでしょうか？
- 「このデザイン、結構いい感じだから、一旦ここでセーブしておこう」
- 「新しいレイアウトを試したいけど、失敗が怖いから、今の状態でセーブしてからにしよう」
- 「あ、AIに壊された！でも大丈夫。5分前のセーブポイントに戻ればいい」
この記事は、そんな魔法のような開発環境を、プログラミング知識ゼロの非エンジニアであるあなたが手に入れるための、具体的で実践的なガイドブックです。
主役となるのは、AIエージェント「Manus」と、エンジニアの世界の標準装備である「Git」そして「GitHub」。この三者を連携させることで、私たちはついに、AI開発における「セーブ＆ロード」の権利を手にすることができます。
これにより、あなたは3つの自由を手に入れるでしょう。
- クレジットの自由：無駄な試行錯誤によるManusクレジットの消費を劇的に抑え、本当に価値ある創造に集中できます。
- 心理的な自由：失敗を恐れることなく、大胆なアイデアを次々と試せるようになります。「壊されても戻せる」という安心感が、あなたの創造性を解放します。
- 場所と時間の自由：あなたの開発環境は、PCの中だけでなく、いつでもどこでもアクセスできる「Web上の安全な倉庫」に保管されます。
もう、AIの気まぐれに怯える必要はありません。これからは、あなたが開発の主導権を握るのです。
📝2026年は非エンジニアもGitHubからは逃れられない、とうか必修項目だと思ってる
@tetumemo
そして最近ManusがGitHub連携できるようになったので、いよいよ自然言語だけでも理解しやすい環境が整った
ということで、
以下のような流れを体験できるようにニュースレターを執筆中… https://t.co/btO368bAZgpic.twitter.com/oicnKNaNnS— テツメモ｜AI図解×検証｜Newsletter (@tetumemo) January 12, 2026
🎙️ニュースレターの内容をAI音声でキャッチアップ！
記事の内容を、有料購読エリアの概要も含めて紹介しています。
ぜひこちらも一緒にフォローしていただき、”ながら聴き”も楽しんでみてください♪
これから歩む冒険の地図（ロードマップ）
この記事は、あなたが「セーブポイント」を使いこなし、自由な開発者になるまでを、4つのステージに分けてナビゲートします。まるでロールプレイングゲームのマップのように、一つずつステージをクリアしていくことで、あなたは着実にレベルアップしていくでしょう。
ステージ | タイトル | ここで手に入るスキル |
|---|---|---|
1 | 最初のセーブポイントを作る | ManusとGitHubを連携させ、開発の歴史を記録する「セーブ」の基本技術 |
2 | ポートフォリオサイトを構築する | Manusへの実践的なプロンプト指示と、デザインを形にするための具体的な対話術 |
3 | 一人チーム開発で未来の自分を助ける | スマホからの開発体験と、ローカル環境からの開発体験、そしてManusへ自然な同期を経験 |
4 | 完成版の公開 | Manus、Claude、Google Antigravityで変更した内容をOKしてサイトの公開！ |
さあ、準備はいいですか？
あなたのAI開発に、決して消えることのないセーブポイントを刻む冒険が、今、始まります。
ワンポイントTip：AI開発の失敗は、あなたのせいではありません。問題は「セーブポイントがない」という開発プロセスそのものにありました。この記事では、ManusとGitHubを使って、誰でも安全に開発できる「セーブ機能」を手に入れる方法を解説します。
🛠️ ステージ1＆2：実践！Manusサイト構築と初めてのセーブポイント
お待たせしました。ここからが、私たちの冒険の核心部分です。序章で語られた「セーブポイントのない絶望」から脱し、真の創造的な自由を手に入れるための、具体的で実践的なステップに踏み出します。
通常、一般的にGitやGitHubの解説するサイトでは、まず道具（GitHub）の準備から入ります。
すると、Git、GitHub、リポジトリ、プッシュ、プル、マージ、クローン…と専門用語が続き、もうこの時点で読む気が失せてしまうんですよね…
（※あ、この用語はまだわからなくて大丈夫です、調べなくてOKです）
で、この流れだと使うかわからない英単語を「絶対重要だからさ！知っておけ！」という半ば強制的に覚える必要性に迫られる…と、挫折へ半歩踏み出しちゃいます。
そこで今回私が解説する方法は「逆説的な流れ」で物語を再構築することにしました。
つまり、まず作りたいもの作り始め、その過程で「セーブしたい！」「変更したい！」「スマホで変更してみたい！」「PCでも変更してみたい！」という必然性を感じ、その解決策としてGitHubと出会う。 この流れこそ、私たちのリアルな体験に近いのではないかと思いました。
これが実現できると思ったのは、ManusがGitHubと連携できるようになったおかげです。
Manusは非エンジニアでも自然言語だけでエンジニア並みの”やりたいこと”が実現できてしまうツールです。
この「自然言語」のみでGit×GitHubが理解できると思いました。
📕「ManusとGitHubの連携：開発の力を最大限に引き出す完全ガイド」がわかりやすくて有益！
@tetumemo
数年前「GitとGitHubを学ぼう」と決意したあの日のことを覚えている
エンジニアの友人に勧められて、Progateを開き、Udemyの講座を買い、YouTubeのチュートリアルを見た
そして、10分後には挫折していた… https://t.co/wBcSTglmuvpic.twitter.com/KmlUxrBaAe— テツメモ｜AI図解×検証｜Newsletter (@tetumemo) January 8, 2026
| テーマを入力→10分待つ→ZIP開ける→全部完成してる。調査、記事、美しい日本語画像、X投稿文。これが「Manus×Nano Banana Pro×魔法のメタプロンプトのチカラ」 |
|
||
|
まずは作ってみよう！Manusとの対話によるサイト構築
何事も、まずは手を動かしてみるのが一番です。百の理論より、一の実践。私たちはまず、Manusという強力なAIパートナーと共に、ポートフォリオサイトの制作を開始します。
今回私、テツメモの活動をまとめた、ポートフォリオサイトを作ることにしました。最初から複雑なサイトやアプリを作成すると、GitHub連携の流れを学ぶ前に疲弊してしまうので、ポートフォリオのようなLPを作ることをオススメします。
私の場合、コンセプトは「シンプルでプロデザイナーが構築した誰にでも愛されて使いやすいミニマルなサイト」です。
この段階では、まだGitHubのことは忘れてください。今はただ、あなたの頭の中にあるイメージを、言葉（プロンプト）を通じてManusに伝え、形にしていくことだけに集中します。
「思考の壁打ち」としてのプロンプト
AIへの指示、つまりプロンプトは、一方的な命令書である必要はありません。むしろ、優秀なアシスタントとの「思考の壁打ち」と捉えるべきです。最初から100点満点の指示を出そうと気負う必要は全くありません。
まずは、あなたの要望を大まかに伝え、AIからのフィードバックを受けながら、徐々に解像度を上げていく。この対話的なプロセスこそが、AI開発の醍醐味です。
ここで、私が実際にこのポートフォリオサイトを作るために、Manusに投げた「プロンプト」を共有します。この生々しい思考のプロセスこそ、あなたの参考になるはずです。
あなたはプロのフロントエンドエンジニア兼UI/UXデザイナーです。
目的：
私、「テツメモ：@tetumemo」を紹介するポートフォリオサイトを、静的サイトとして構築してください。
私のポートフォリオサイトは以下のとおりです。
- 【ニュースレターサイト】「【週刊】今日から始めるAI生活」https//tetumemo.m-newsletter.com/
- 【note】https//note.com/tetumemo
- 【X】https//x.com/tetumemo
- 【Spotify】https//open.spotify.com/show/6k8BkUSo2UgnWJSXwtWL92
サイトの構成としてメインである「https//tetumemo.m-newsletter.com/」から直近2ヶ月文の記事情報を取得して概要をピックアップして紹介するようにしてください。
また、Xからは「https//x.com/tetumemo/highlights」のハイライトから自動的に10投稿を取得して掲載するようにしてください。これは自動更新されていきます。
という指示をしようと思っているけど、指示で不足してる部分があればステップバイステップでユーザーに一問一答で確認して
💡ここがポイント！この一言を文末に追加で精度が向上します！
という指示をしようと思っているけど、指示で不足してる部分があればステップバイステップでユーザーに一問一答で確認して
このプロンプトをManusに投げかけると、Manusは即座にサイトを作り始めるのではなく、まずあなたに対して質問を返してくるでしょう。例えば、
- 「承知しました。サイトのデザインコンセプトについて、もう少し詳しく教えていただけますか？例えば、参考にしてほしいサイトの雰囲気や、メインで使用したい色などはありますか？」
- 「ニュースレターとXの投稿は、どのようなレイアウトで表示するのが理想ですか？画像を大きく見せるカード形式、あるいはシンプルなリスト形式など、ご希望はありますか？」
- 「自動更新機能についてですが、これはサイト訪問者がアクセスするたびに最新情報を取得する形でよろしいでしょうか？それとも、1日に1回など、定期的に更新する形でしょうか？」
このように、AIが質問を返してくれることで、自分一人では気づかなかった要件や、曖昧だった部分が明確になっていきます。この対話を数回繰り返すことで、サイトの設計図はどんどん詳細で、強固なものになっていくのです。
「今、セーブしたい！」- 必然として訪れるセーブポイントの必要性
Manusとの対話を通じて、サイトの骨格が見えてきました。ヘッダーにはタイトルとロゴが配置され、メインエリアにはコンテンツが並び、フッターにはコピーライトが表示される。デザインの方向性も固まり、かなり「いい感じ」になってきました。
まさに、この瞬間です。あなたの心の中に、こんな感情が芽生えるはずです。
「この状態、すごく良い。この状態を、絶対に失いたくない。ここに『セーブポイント』を作りたい！」
ここからさらに踏み込んだ修正を加えたい。でも、もし次の指示でAIが誤解して、この美しいレイアウトが崩れてしまったら？あの悪夢が再び訪れるのではないか？
この自然発生的な「保存したい」という欲求こそ、バージョン管理、すなわち「セーブ」の必要性を、理屈ではなく魂で理解する瞬間です。理論から入るのではなく、実践の中で生まれたこの切実なニーズこそが、新しいツールを学ぶ最強のモチベーションになります。
そして、この「セーブポイント」を作る仕組み、実はちゃんとあるんです。
それが「Git（ギット）」と「GitHub（ギットハブ）」。この記事のタイトルにも入っているツールです。
名前が似ているので混同しがちですが、こう考えるとわかりやすいです：
- Git = ゲームのセーブ機能の「ルール」そのもの。「この瞬間を記録する」「過去に戻る」といったセーブ・ロードの仕組みを定めた約束事。
- GitHub = セーブデータを保管する「クラウド倉庫」。Gitのルールで記録したセーブポイントを、インターネット上に安全に保管しておける場所。→何と無料で使える！
そして今回使うManusは、このGitのルールを最初から組み込んだ「クラウド開発環境」
つまり…
Manusの中で作業 → Gitのルールでセーブ → GitHubの倉庫に保管
昔のゲームは「ゲーム機本体にセーブ→あとでUSBに移す」という二段階でしたが、今のクラウドゲームは最初からクラウド上でプレイして、セーブも自動的にクラウドに保存されますよね？Manusも同じです。
あなたのパソコンには何もインストールしなくていい。Manusというクラウド上の開発環境で作業して、「この状態を保存したい」と思ったら、そのままGitHubに記録される。この手軽さこそが、クラウド開発の魅力なんです。
今のあなたが感じている「この状態を守りたい」という欲求。それを叶えるために生まれたのがGitであり、そのデータを安全に保管するのがGitHubであり、その全てをブラウザだけで実現するのがManusなんです。
運命のクリック：ManusのGitHub連携ボタン
その切実な願いを叶える鍵は、Manusのインターフェースの中に、静かにあなたを待っています。画面の右上を見てください。そこには、見慣れないアイコンがあるはずです。そう、猫のようなタコのような、不思議な生き物のアイコン… GitHubアイコンです。
このボタンこそが、あなたの開発プロセスに革命をもたらす「セーブポイント作成ボタン」への入り口です。勇気を出して、このアイコンをクリックしてみましょう。するとはじめてGitHubが起動します。
シナリオA：GitHubアカウントを「持っていない」場合
おそらく、この記事を読んでいる多くの非エンジニアの方が、こちらのシナリオに該当するでしょう。アイコンをクリックすると、「接続されたアカウントはありません」といったメッセージが表示されます。
これは、セーブデータを保管するための「Web上の安全な倉庫（GitHub）」の鍵を、あなたがまだ持っていないことを意味します。
でも、全く問題ありません。むしろ、ここからが本番です。私たちは今、明確な目的を持って、この倉庫の鍵を手に入れる旅に出るのですから。
ステップ1：GitHubとは何かを理解する
ここで改めて、GitHubとは何かを、私たち非エンジニアの言葉で定義し直しましょう。
GitHubとは、「Web上にある、あなた専用の超安全な貸金庫」です。
この貸金庫には、あなたが作ったWebサイトの設計図（コード）を、好きなタイミングで、好きなだけ保管しておくことができます。しかも、ただ保管するだけではありません。「2日前の15時の状態」「デザインを修正する直前の状態」といったように、過去のあらゆる時点のデータを完璧に記録し、いつでも好きな時点の設計図を取り出すことができる「タイムマシン機能付きの貸金庫」なのです。
ステップ2：アカウントを作成し、貸金庫の鍵を手に入れる
それでは、この強力な貸金庫の鍵（アカウント）を手に入れましょう。Manusの画面に表示されているリンクか、以下の公式サイトにアクセスしてください。
アカウント作成は無料です。画面の指示に従って、Googleなどのシングルサインオンか、メールアドレス、パスワード、ユーザー名などを入力して登録します。このプロセスは、一般的なWebサービスへの登録と何ら変わりません。身構える必要は全くありません。
これで準備は完了です。あなたは今、Web上に自分だけのタイムマシン機能付き貸金庫を手に入れました。
シナリオB：GitHubアカウントを「すでに持っている」場合
※シナリオAが完了した方も同じ
もしあなたがすでにGitHubアカウントをお持ちの場合、話はさらに早いです。GitHubアイコンをクリックすると、ManusがあなたのGitHubアカウントと連携するための許可を求めてきます。
画面には上のような認証画面が表示され、「どのリポジトリへのアクセスを許可しますか？」と尋ねられます。
💡 「リポジトリ」って何？
リポジトリ（Repository）とは、プロジェクトごとの「保管ボックス」のこと。GitHubという大きな貸金庫の中に、「ポートフォリオサイト用」「ブログ用」「アプリ開発用」といった具合に、プロジェクトごとに分かれた保管ボックスがあるイメージです。それぞれのボックスに、そのプロジェクトのファイルとセーブポイント（履歴）が入っています。
「すべてのリポジトリ（All repositories）」か「選択したリポジトリのみ（Only select repositories）」を選べます。
今回はManusがGitHubに今回のポートフォリオサイト用の新しいリポジトリ（保管ボックス）を作って、そこにプロジェクトを保存します。そのため「すべてのリポジトリ」を選んでおきましょう。
「Install」や「Authorize」といったボタンを押せば、認証は完了です。
連携完了！そして、記念すべき最初のセーブ
もう一度、ManusのGitHubアイコンをクリックしてみてください。
今度は違います。今回作成したサイトを保管庫に保存するためのリポジトリを作成します。名前は「tetumemo-portfolio」にしました。
これであなたが作成したリポジトリ名が表示され、緑色のチェックマークが輝いているはずです。
おめでとうございます！
これで、Manusでの変更は自動的にGitHubへセーブ（コミット）されるようになりました。ゲームのオートセーブのように、作業内容が勝手に記録されていくんです。
※GitHubにManusで作成したファイル一式アップロードされました
実際に確認してみましょう。何か小さな変更を加えてみてください。文章を一行追加するだけでもOKです。すると、Manusが自動的にその変更を検知し、GitHubへアップロード（プッシュ）してくれます。
画面右上のGitHubアイコンの左アイコンをクリックしてください。「10秒前にプッシュ」といった表示が出ているかもしれません。これが、あなたの開発史が、今この瞬間も記録され続けている証拠です。
💡 重要：Manusの「自動セーブ」の正体
Manusは変更を検知すると、自動的に「コミット（記録）」して「プッシュ（GitHubへアップロード）」してくれます。つまり、あなたは何もしなくても、作業の軌跡がすべて保存されていくんです。
あの「いい感じの状態を失いたくない」という不安は、もう過去のものです。
今この瞬間から、あなたのAI開発は、後戻りのできない綱渡りから、何度でもやり直せる安全な実験へと変わりました。
ワンポイントTip：ツールの学習は、目的を持って初めて意味をなします。「セーブしたい」という切実な欲求が生まれた時こそ、GitHubのような新しいツールを学ぶ絶好のタイミング。実践の中から生まれた「なぜ？」を大切にしましょう。
🚀 特別補講：AIとの冒険を記録する「Gitサイクル」完全マスター
ステージ1＆2で、私たちはManusという頼れる相棒と共にWebサイトを創造し、その大切な成果を失わないための「最初のセーブポイント」をGitHubに築きました。AIが予期せぬ変更を加えても、いつでも元に戻せる。この安心感は、まさに冒険に不可欠な命綱です。
でも、ちょっと待ってください。セーブポイントを作れるようになったのは素晴らしい。でも、それだけで満足していいんでしょうか？
ゲームで例えるなら、今のあなたは「セーブはできるけど、ロードの仕方を知らない」状態なんです。せっかく作ったセーブポイントなのに、それをどう活用すればいいのか、まだ十分には理解していないかもしれません。
この補講では、セーブポイントをただ作るだけでなく、それを自在に操り、過去と現在を自由に行き来するための、開発の基本的なリズム――「Gitサイクル」を完全にマスターします。
具体的には、
- サイトに小さな変更を加え、その意図を「意味のある塊」としてセーブする（コミット）
- セーブした歴史を一覧し、過去の状態を覗き、時には過去に戻る（タイムトラベル）
という、プロの開発者が日々実践している核心的なワークフローを、ManusとGitHubの両方の視点から、どこまでも丁寧に解き明かしていきます。
このサイクルを体得した時、あなたはもはや単なるAIの利用者ではなく、AIを巧みに導き、共に創造の旅路を歩む「開発者」としての、確かな一歩を踏み出すことになるでしょう。
開発のリズムを刻む：小さな変更と、未来への申し送り
突然ですが、質問です。
あなたは今まで、こんな経験はありませんか？
夜遅くまでかけて資料を作り、「よし、完璧！」と思って保存。翌朝開いてみたら、「あれ？昨日の途中の状態の方が良かったかも…」と後悔する。でも、もう戻れない。上書き保存してしまったから。
この絶望感、プロの開発者も同じように感じていたんです。だからこそ、Gitというツールが生まれました。
優れた開発は、一度に大きな山を動かそうとはしません。それは、小さな石を一つひとつ、確実な歩みで積み上げていく作業に似ています。基本のリズムは「1つの作業が終わったら、1つセーブする」。この心地よいリズムを、まずは体に覚え込ませましょう。
ステップ1：AIに「具体的」な変更を指示する
私たちのポートフォリオサイトに、簡単な変更を加えてみます。例えば、ニュースレターとXの投稿の表示件数を、現在の数から「10件」に変更してみましょう。この指示を、Manusに自然な言葉で伝えます。
NEWSLETTERとX_LOGSは10件表示させてください。
Manusは即座に指示を理解し、必要なファイルの編集に取り掛かります。そして、作業が完了すると、人間のアシスタントのように丁寧に結果を報告してくれます。
このように、変更内容と、さらなる改善のための「次のステップ」まで提案してくれるのが、Manusの素晴らしいところです。私たちは、この提案を元に、次の作業計画を立てることができます。
ステップ2：未来の自分のために「意味のあるセーブ」を行う
さて、ここからが本題です。
表示件数が10件になり、サイトが意図通りに更新されたことを確認したら履歴を確認してみましょう。
Manusは自動的に何を変更したのかを英語でメッセージを残してくれます。
これがセーブする際に必ずセットで実施する「コミットメッセージ」です。
ただ、ちょっと英語だとわかりにくいですよね。
そんなわかりにくさをなくすために「良いコミットメッセージ」のお作法を学んでおきましょう！
「えっ、メッセージ？面倒くさくない？」
そう思いましたか？でも、ちょっと想像してみてください。
3ヶ月後のあなたが、「あれ、このサイトのこの部分、なんでこうなってるんだっけ？」と疑問に思ったとします。過去のセーブポイント一覧を見てみると、そこには：
修正
変更
更新
fix
update
こんなメッセージしか残っていなかったら？
…絶望しますよね。
このメッセージは、数日後、数ヶ月後の自分、あるいは（一人チーム開発における）もう一人の自分への「申し送りメモ」です。単に「修正」とか「変更」といった曖昧な言葉では、未来の自分は「一体、何を変更したんだっけ？」と頭を抱えることになります。
「何のために、何を、どのように変更したのか」が、一目でわかるように記述する
これが、開発者の鉄則です。
良いコミットメッセージは、未来の自分への最高のプレゼントです。例えば、今回の変更なら、こんなメッセージはどうでしょう。
feat NEWSLETTERとX_LOGSの表示件数を10件に変更
- ユーザーからの視認性向上のため、初期表示件数を調整
- NEWSLETTERの表示件数を6件から10件に設定
- X_LOGSの表示件数を6件から10件に設定
最初の行（feat: NEWSLETTERと...）が「見出し」、その下の箇条書きが「詳細説明」です。
見出しのコツ：
feat:（新機能追加）、fix:（バグ修正）、update:（更新）など、変更の種類を最初に書く- 何を変更したかを端的に（50文字以内が理想）
詳細説明のコツ：
- なぜこの変更が必要だったのか（理由）
- 具体的に何を変更したのか（内容）
- 変更前と変更後の状態
ManusのGitHub連携機能を使えば、このような詳細なメッセージを添えて、ワンクリックで変更をセーブできます。セーブが完了すると、Manusの画面には「最新の状態です」と表示され、最新のコミットメッセージが確認できます。
ただ、Manusは自動的にコミットメッセージを付けて自動保存してくれますよね？
その点を考慮して、プロンプトの指示文の最後には以下の一言を添えるだけでも随分かわります。
「コミットする際は変更点を箇条書きで端的にまとめて、日本語でメッセージを作成してください。」
この操作により、あなたの変更は、Web上の安全な貸金庫（GitHubリポジトリ）に、タイムスタンプとメッセージと共に記録されました。
※コミットメッセージを日本語で入力してもらいました
💡 ちなみに：良いコミットメッセージの副次効果
丁寧なコミットメッセージを書く習慣は、実は「自分の作業を振り返る」良い機会にもなります。「今日は何をしたんだっけ？」と考えることで、作業の整理にもなるんです。日記のような感覚ですね。
時をかける冒険：バージョン履歴とタイムトラベル
セーブポイントを積み重ねていくと、あなたのプロジェクトには「歴史」が生まれます。そして、その歴史を自由に旅することができるのが、バージョン管理の真の力です。
ここで、冒頭の問いに戻りましょう。
「昨日の途中の状態の方が良かったかも…」
もう、この絶望を味わう必要はありません。なぜなら、あなたは今、タイムマシンを手に入れたからです。
ステップ3：セーブの歴史を一覧し、過去の世界を覗く
Manusは、これまでのセーブの歴史を、非常に分かりやすい形で一覧表示してくれます。画面右上のメニューから「バージョン履歴」を選択してみてください。
そこには、あなたがこれまで行ってきたセーブ（コミット）が、新しいものから順にリストアップされています。それぞれの項目には、コミットメッセージとその時点でのサイトのプレビューが表示されており、プロジェクトがどのように変化してきたかを一目で把握することができます。
この一覧を見てみてください。
先ほど書いた丁寧なコミットメッセージが、こうして並んでいると、プロジェクトの「物語」が見えてきませんか？
「最初にレイアウトを整えて、次にニュースレターのリンクを修正して、そして表示件数を増やして…」
これが、バージョン履歴の真の価値です。単なる記録ではなく、あなたの創造の軌跡なんです。
ステップ4：過去の世界へ、安全なタイムトラベル
「あの時のデザイン、どうだったかな？」
そう思ったら、履歴の中から気になるバージョンを選んで「プレビュー」ボタンを押してみてください。あなたのサイトは、そのセーブポイントが作られた、まさにその瞬間の姿に切り替わります。
画面の上部には「古いバージョン(ddc2c76e)をプレビューしています」という黄色いバーが表示され、今が「タイムトラベル中」であることが示されます。
このプレビュー機能は、現在の状態に一切影響を与えません。つまり、過去を覗いても、現在が壊れることはないんです。安心して、心ゆくまで過去を探索できます。
「ちょっと待って、これって…ドラえもんのタイムテレビみたいじゃない？」
まさに、その通り！過去を見るだけ見て、気が済んだら現在に戻ってくる。それが、このプレビュー機能です。
ステップ5：過去に戻る決断（ロールバック）
さて、プレビューの結果、あなたはこう思ったとします。
「やっぱり、この過去のバージョンの方が良かった。今の状態は気に入らない」
大丈夫です。あなたは、その時点にプロジェクト全体を戻すことができます。それが「ロールバック」です。
プレビュー画面に表示されている「このバージョンにロールバック」ボタンを押すだけ。
たったこれだけの操作で、あなたのサイトは、選択した過去のバージョンの状態に完全に戻ります。
- AIが加えた望まない変更も
- あなた自身が犯してしまったミスも
- すべてが「なかったこと」になる
これこそが、私たちが手に入れたかった「絶対的な安心感」の正体です。
もう、「上書き保存しちゃった…」と絶望する必要はありません。何度でもやり直せるんです。
💡 重要：ロールバックは「新しいセーブポイント」を作る
ロールバックは、単に過去に戻るだけではありません。正確には「過去の状態を、新しいセーブポイントとして記録する」という動作です。つまり、履歴は残り続けます。後で「やっぱりロールバック前の方が良かった」と思ったら、またロールバックできるんです。安心ですよね。
冒険の裏側：GitとGitHubの仕組みを覗いてみよう
さて、ここまで体験してきた魔法のようなタイムトラベル。その裏側では、一体何が起きているのでしょうか？
「いや、別に知らなくてもManusが全部やってくれるし…」
確かに、その通りです。でも、少しだけ裏側を知っておくと、あなたの冒険はさらに自由で、創造的なものになります。
難しい話は最小限に。でも、知っておくと確実に役立つ知識だけを、ここで整理しておきましょう。
GitとGitHubの違い：タイムマシンと、その記録を保管するクラウド書庫
何度も繰り返しますが例えも変えつつ、よく混同されがちなこの2つの言葉を整理します。
- Git：あなたのPC（あるいはManusの環境）の中で動く、「ファイルの変更履歴を記録・管理するツール」そのものです。セーブポイント（コミット）を作ったり、過去のセーブポイントに戻ったりするタイムマシンのような存在だと考えてください。
- GitHub：Gitが記録した変更履歴（リポジトリ）を、インターネット上の安全な場所で預かってくれるWebサービスです。チームで開発するときの作戦会議室であり、世界中の開発者に自分の作品を公開したりするための巨大なクラウド書庫です。
例えるなら：
- Git：あなたの家にある「大切な写真アルバム」
- GitHub：その写真アルバムのコピーを預かってくれる「貸金庫サービス」
家が火事になっても、貸金庫にコピーがあれば安心ですよね。それと同じです。
Manusは、Gitというタイムマシンを内蔵しており、あなたが指示した変更を自動で記録します。そして、「GitHub連携」を行うことで、その記録をGitHubというクラウド書庫に送り、保管しているのです。
コミットの正体：3つのエリアを巡る旅
「コミット」という言葉、何度も出てきましたね。でも、その裏側で何が起きているのか、もう少しだけ深く理解しておきましょう。
あなたがManus上で「セーブ」を行うとき、裏側ではGitが少し複雑な手順を踏んでいます。Gitの世界には、大きく分けて3つのエリアが存在します。
- 作業ディレクトリ（ワーキングツリー）
あなたが今、まさに作業している場所。いわば「作業机」です。Manusがファイルを編集している、まさにその現場です。 - ステージングエリア（インデックス）
次のセーブ（コミット）に含める変更を、一時的に置いておく場所。「発送用の段ボール箱」のようなものです。 - リポジトリ
ステージングエリアにある変更を、メッセージと共に記録し、保管する場所。「タイムスタンプ付きの記録が並ぶ倉庫」です。
セーブ（コミット）という1つの行為は、実は2つのステップに分かれています。
git add：作業机の上にある変更済みのファイルを、発送用の段ボール箱に入れる作業。git commit：段ボール箱に「表示件数を10件に変更」といったラベルを貼り、封をして、倉庫の棚に保管する作業。これがセーブポイント作成の瞬間です。
Manusはこれを自動で行っています。
「えっ、なんで2段階なの？面倒くさくない？」
良い質問です！この2段階があるからこそ、「どの変更を今回のセーブに含めるか」を正確にコントロールできるんです。
例えば、あなたがManusを使わずローカル環境で5つのファイルを同時に編集していたとします。でも、そのうちの3つは「機能A」の作業で、残りの2つは「機能B」の作業だったとしたら？
この場合、機能Aの3ファイルだけをステージングエリアに入れて、「feat: 機能Aを追加」というコミットを作る。次に、残りの2ファイルをステージングに入れて、「feat: 機能Bを追加」という別のコミットを作る。
こうすることで、将来「機能Aのコミットだけを取り消したい」といった操作が可能になるんです。
まあ、Manusを使っている限りは、この辺りはすべて自動でやってくれます。でも、裏側で何が起きているかを知っていると、より高度な操作にも挑戦できるようになります。
コミットは「差分」で記録される
もう一つ、知っておくと面白い事実。
コミットは、毎回プロジェクト全体をコピーして保存しているわけではありません。「前回のセーブポイントから、何が変わったか」という差分（diff）だけを記録しています。
例えば：
- 1回目のコミット：全ファイル（100KB）を記録
- 2回目のコミット：変更した3行（0.5KB）だけを記録
- 3回目のコミット：変更した5行（1KB）だけを記録
こうすることで、何百回、何千回とセーブを重ねても、容量がパンクしないんです。賢いですよね。
そして、過去のバージョンを見たいときは、Gitが「最初のコミット＋差分1＋差分2＋…」と、差分を積み上げて、その時点の状態を再現してくれます。
これが、Gitが「タイムマシン」と呼ばれる理由です。魔法ではなく、きちんとした仕組みがあるんです。
まとめ：Gitサイクルをマスターしたあなたへ
さあ、この補講を通じて、あなたは以下のことができるようになりました：
- 意味のあるセーブポイントを作る
丁寧なコミットメッセージと共に、作業の節目節目でセーブする習慣 - 過去の歴史を一覧し、安全にタイムトラベルする
プレビュー機能で過去を覗き、必要ならロールバックで過去に戻る - GitとGitHubの仕組みを理解する
裏側で何が起きているかを知ることで、より自信を持って使える
これが、開発の基本的なリズム「Gitサイクル」です。
最初は「面倒くさいな」と思ったかもしれません。でも、一度この習慣が身につくと、もう元には戻れません。
なぜなら、この安心感――いつでも過去に戻れる、何度でもやり直せる――は、あなたの創造性を解放するからです。
失敗を恐れなくなります。大胆な挑戦ができるようになります。「これ試してみたいけど、壊れたらどうしよう…」という不安が消えます。
これこそが、プロの開発者が日々感じている「自由」の正体です。
そして今、あなたもその自由を手に入れました。
次のステージでは、この基本を土台に、さらに高度な「一人チーム開発」の世界へと進んでいきます。複数のデバイス、複数の役割を自在に使い分け、まるでチーム全体を一人で動かすかのような、驚くべきワークフローを体験していきましょう。
準備はいいですか？さあ、冒険を続けましょう！
ワンポイントTip：完璧なコミットメッセージを目指さなくてOK
最初のうちは、コミットメッセージを書くのに時間がかかるかもしれません。でも、完璧を目指す必要はありません。「何を変えたか」が分かれば十分。慣れてくれば、自然とより良いメッセージが書けるようになります。まずは、習慣化することが大切です。
🎭 ステージ3：時と場所を超える「一人チーム開発」という名の協奏曲
これまでの冒険で、私たちはManusという強力なAIエージェントを相棒に、Webサイトを創造し、その成果を失わないための「セーブポイント」をGitHubに築き、さらにはGitの基本的なサイクルをマスターしました。あなたはもう、AIによる予期せぬ変更を恐れることなく、過去の任意の時点にプロジェクトを戻す「タイムトラベル」さえ可能です。
しかし、私たちの旅は、まだその序章を終えたに過ぎません。
このステージ3では、これまでの知識を統合し、さらに昇華させる、全く新しい開発スタイル――「一人チーム開発」というコンセプトを導入します。
なぜ「一人」で「チーム」を演じるのか？
突然ですが、想像してみてください。
あなたは今、電車の中です。PCはありません。スマートフォンだけが手元にあります。
ふと、昨日Manusで作ったポートフォリオサイトのことを思い出します。「あ、あそこのニュースレターのリンク、間違ってたな。直さないと」
こんな時、あなたならどうしますか？
従来なら、「家に帰ってPCを開いて…」と諦めるしかありませんでした。でも、今は違います。スマートフォンとAIがあれば、その場で修正できるんです。
そして、その修正内容は、自動的にあなたのPCやManusに同期できる。
まるで、複数の自分が同時にプロジェクトに取り組んでいるように。
これが「一人チーム開発」の真髄です。
GitやGitHubがその真価を最大限に発揮するのは、複数の人間が一つのプロジェクトに同時に携わる「チーム開発」の場面です。しかし、いきなり見知らぬ誰かとチームを組むのは、少しハードルが高いかもしれません。
そこで、あなた自身が複数の役割を演じ分け、擬似的にチーム開発を体験してみるのです。この「一人チーム開発」という名のロールプレイングゲームを通じて、あなたはGitのコマンドを単なる「呪文」から、他者と協力し、プロジェクトを円滑に進めるための「共通言語」へと進化させることができます。
登場人物（あなたの分身たち）を紹介しよう
このステージで、あなたは以下の3人のキャラクターを演じ分けます。
- Aさん（あなた自身・リーダー）：プロジェクト全体の方向性を決め、Manusを駆使して大胆にプロトタイプを作り上げる、創造の起点となる存在。
- Bさん（同僚・効率化の鬼）：PCの高機能な開発環境（IDE:Google Antigravity）を使い、Manusのクレジットを節約しながら、細部の作り込みや大規模な修正を行う、実務のエキスパート。
- Cくん（後輩・機動力のスペシャリスト）：移動中の電車の中など、場所を選ばずにスマートフォンからプロジェクトにアクセスし、文章の修正やアイデアの追加、レビューを行う、フットワークの軽いメンバー。
そして、この3人が集う作戦会議室であり、プロジェクトの唯一無二の「正史」が保管される場所、それがGitHubです。
この章では、まず「Cくん」の役割に焦点を当て、スマートフォンとClaude Code（Web版）を駆使して、PCがない場所からでもプロジェクトを改善していく、驚くほど現代的でパワフルなワークフローを、ステップ・バイ・ステップで体験していきます。
そして、この実践を通じて、あなたは自然とプロ開発者の必須技術を体得することになります。
さあ、あなた自身との華麗なる協奏曲を奏で始めましょう。
Part 1：後輩Cくん、スマホ片手に参上！ (Claude Code編)
あなたは今、外出先でスマートフォンを眺めている「後輩Cくん」です。PCは手元にありません。しかし、あなたの頭の中には、昨日AさんがManusで作ったポートフォリオサイトの、いくつかの改善点が浮かんでいます。
- ニュースレターの紹介カードに、不要な画像が表示されていてレイアウトが崩れている。
- そもそも、表示されているニュースレターの情報が古く、リンクも間違っている。
- X（旧Twitter）の投稿も、途中からリンクが切れてしまっている。
「でも、PCないしなぁ…」
いえいえ、諦めるのはまだ早い。今の私たちには、スマートフォンと、強力なAIアシスタント「Claude」がいます。さあ、ポケットの中から開発を始めましょう。
ステップ1：Claude Codeにスマホでアクセスする
まずは、ClaudeのスマホアプリからClaude Codeにアクセスします。
ここから、Manusで作成したポートフォリオサイトのリポジトリ「tetumemo-portfolio」を選びましょう。
ステップ2：修正したい内容を指示する
Claude Codeが起動したら、チャット欄に具体的な指示として伝えます。
■ニュースレターについて
ニュースレターの紹介カードには画像は不要なので削除してレイアウトを整えてください。
ニュースレターのリンク切れも起こさないようにしてください。
タイトルと時系列、リンク情報が合っていません。
私が執筆していない情報も含まれています。
取得するURLはこちらのみです。
https//tetumemo.m-newsletter.com
VIEW ALL ARCHIVES. も上記サイトリンクを仕込んでください。
■Xリンク
X LOGSの6ポスト目以降のリンク切れがあります。リンク切れを起こさない構成にしてください。
※コミットメッセージは英語と日本語でお願いします。
ここでの指示が、Cくんの腕の見せ所です。曖昧な指示ではなく、プロのディレクターのように、的確かつ網羅的に修正点を伝えます。
ステップ3：Claude Codeが魔法をかける
指示を受け取ったClaude Codeは、凄まじい速さで思考を巡らせます。
- 指示された内容を把握
- 問題点を分析
- 修正案を生成
- 修正されたコードを提示
そして、最も重要なこと――Claude Codeは、あなたのGitHubリポジトリに直接アクセスし、自動的に新しい「ブランチ」を作成します。
「ブランチ？なにそれ？」
大丈夫、今は分からなくても構いません。これから体験を通じて理解していきますから。
ステップ4：「ブランチ（支店）」という並行世界の誕生
ここで、極めて重要な出来事が起きました。
Claude Codeは、あなたの指示に従って修正を行う際、本番のコード（mainブランチ）には一切触れず、代わりに「claude-code-fix-newsletter」という名前の新しい世界を作り出したのです。
これが「ブランチ（Branch）」です。
ブランチとは、プロジェクトの歴史の本流から枝分かれして、本番に一切影響を与えずに作業を行うための「並行世界（パラレルワールド）」のようなものです。
想像してみてください。
あなたは今、「ニュースレターとXのリンクを修正する」という実験をしています。でも、もしこの修正が失敗して、サイトが壊れてしまったら？
本番のコードを直接いじっていたら、大惨事です。でも、ブランチという「実験用の並行世界」で作業していれば、たとえ失敗しても、本番は無傷のまま。
そして、実験が成功したら、その並行世界での変更を、本番の世界に「マージ（Merge）」すればいいだけ。
これが、プロの開発者が日々実践している、「失敗を恐れずに大胆に挑戦する」ための魔法なんです。
💡 重要：なぜClaude Codeは自動でブランチを作るのか？
Claude Codeは、あなたのプロジェクトを壊さないために、必ず新しいブランチを作成します。これは、AIがコードを書く際の「安全装置」なんです。AIの提案が間違っている可能性もありますからね。ブランチを使えば、レビューしてから本番に反映できます。
ステップ5：GitHubでブランチとプルリクエストを確認する
Claude Codeが作業を完了すると、こんなメッセージが表示されます：
修正が完了しました！
ブランチ「claude-code-fix-newsletter」にコミットし、
プルリクエストを作成しました。
GitHubで内容を確認してください：
https//github.com/tetumemo/tetumemo-portfolio/pull/3
このリンクをタップすると、GitHubの「プルリクエスト」画面が開きます。
「プルリクエスト？また新しい言葉？」
はい、でも難しくありません。プルリクエスト（Pull Request、略してPR）とは、「この変更を本番に取り込んでいいかチェックしてください」というお願いのことです。
プルリクエストの画面では、以下のことが確認できます：
- タイトルとコミットメッセージ
Claude Codeが書いてくれた、変更内容の説明文です。Fix newsletter and X LOGS remove images, clean broken links
ニュースレターとX LOGSの修正 画像削除、リンク切れを修正
- Newsletter Removed image thumbnails from cards for cleaner layout
- Newsletter Removed unverified articles with invalid links (kept only 2 verified articles)
- Newsletter Added link to VIEW ALL ARCHIVES button (tetumemo.m-newsletter.com)
- X LOGS Removed posts 6-10 with broken/invalid status IDs (kept only 5 verified posts)
- Simplified newsletter card layout to text-only design
ニュースレター カードからサムネイル画像を削除してシンプルなレイアウトに
ニュースレター 無効なリンクを持つ未確認の記事を削除（確認済み2件のみ保持）
ニュースレター VIEW ALL ARCHIVESボタンにリンクを追加
X LOGS 壊れたステータスIDを持つ6-10番目のポストを削除（確認済み5件のみ保持） - どのブランチからどのブランチへの変更か
claude-code-fix-newsletter（並行世界）→main（本番）への変更依頼であることが分かります。 - 変更内容の詳細（diff）
「Files changed」タブをタップすると、具体的に何が変わったのか、行単位で確認できます。
緑色の行が「追加された部分」、赤色の行が「削除された部分」です。
ステップ6：変更をレビューし、本番に反映させる（マージ）
さあ、ここが最も重要な瞬間です。
あなたは今、リーダーAさんではなく、後輩Cくんとして、自分が指示した変更が正しく行われているかを確認しています。
変更内容を見て、問題なさそうなら、画面下部の緑色のボタン「Merge pull request」をタップします。
「本当にマージしていいですか？」という確認が出るので、「Confirm merge」をタップ。
おめでとうございます！
この瞬間、並行世界（claude-code-fix-newsletterブランチ）での変更が、本番の世界（mainブランチ）に統合されました。これが「マージ（Merge）」です。
マージが完了すると、GitHubは自動的にそのブランチを削除するかどうか聞いてきます。「Delete branch」をタップしておきましょう。もう役目を終えた並行世界なので、整理しておくのがベストプラクティスです。
💡 なぜマージ前にレビューするのか？
AIは賢いですが、完璧ではありません。時には、あなたの意図とは違う修正をすることもあります。だからこそ、プルリクエストで変更内容を確認し、納得してからマージする。このワンクッションが、プロジェクトを守る「最後の砦」なんです。
ステップ7：「並行世界」の変更が「本番」に反映されるまでの物語
ここで、今起きたことを整理しましょう。
- Cくんが指示を出す（スマホから）
「ニュースレターとXのリンクを修正して」 - Claude Codeが並行世界を作る
本番（main）はそのまま → 新しいブランチ（claude-code-fix-newsletter）を作成 - Claude Codeが並行世界で修正
本番は無傷のまま、実験的な修正を実施 - Cくんがレビュー（スマホから）
GitHubのプルリクエストで変更内容を確認 - マージで本番に反映
並行世界の変更を、本番にコピー → ブランチ削除
この一連の流れ、実はチーム開発の現場でも、まったく同じように行われています。
例えば：
- 開発者Aさんが新機能を開発（ブランチ作成）
- 完成したらプルリクエストを作成
- チームメンバーがレビュー
- 問題なければマージ
あなたは今、この「プロの開発フロー」を、一人で体験したんです。
ステップ8：リーダーAさん、Manusで結果を確認し、同期する
さて、場面は変わって、リーダーであるAさん（あなた）のPCの前に戻ります。
Aさんは、いつものようにManusのダッシュボードを開きます。そこで先程のGitHubボタンを押すと…
「古いバージョンです」と表示
これは、Cくんがスマートフォンから行った修正が、作戦会議室（GitHub）に届いていることを示しています。
Aさんは「Manusに同期を依頼する」ボタンをクリックします。
すると、ManusはGitHubから最新のデータを取り込み（git pull）、現環境を更新します。
プレビュー画面を見れば、Cくんが修正した通り、ニュースレターのレイアウトが整い、リンクも正しくなっていることが確認できるはずです。
PCがない環境からでも、プロジェクトは着実に前進しました。
これが、GitHubをハブとして、複数のデバイス（そして複数の役割の自分）が連携する「一人チーム開発」の威力です。
バージョン履歴を見ると、美しい一本の歴史が記録されています
- Aさんが最初のバージョンを作成
- CくんがニュースレターとXのリンクを修正（ブランチで作業 → マージ）
- Aさんがその変更を取り込んで確認
まるで、時間と空間を超えて、チームが協力し合っているようです。
「ブランチ」の本質：失敗を恐れない自由
さて、ここまでの体験で、あなたは「ブランチ」という概念を、理屈ではなく肌感覚で理解できたと思います。
改めて整理しましょう。
ブランチとは何か？
ブランチとは、プロジェクトの歴史の本流（通常はmainブランチ）から枝分かれして、本番に一切影響を与えずに作業を行うための「並行世界（パラレルワールド）」です。
なぜブランチが必要なのか？
- 本番を壊さない
実験的な変更を、安全に試すことができる - 複数の作業を並行できる
「機能A」と「機能B」を、別々のブランチで同時進行 - レビューの余地が生まれる
変更を本番に反映する前に、内容を確認できる - 失敗してもOK
ブランチでの変更が気に入らなければ、そのブランチを削除するだけ
ブランチの使い方（基本の流れ）
- ブランチを作る
新しい並行世界を作成（Claude Codeは自動でやってくれます） - ブランチで作業する
本番は触らず、並行世界でコードを書く - プルリクエストを作る
「この変更を本番に取り込んでください」とお願い - レビューする
変更内容が正しいか確認 - マージする
並行世界の変更を、本番に統合 - ブランチを削除
役目を終えた並行世界を片付ける
この流れ、今あなたが体験したばかりですよね。
ブランチがもたらす「心理的安全性」
ブランチの最大の価値は、技術的な便利さだけではありません。
それは、「失敗を恐れなくなる」という、心理的な解放です。
「この変更、うまくいくかな…でも、もし壊れたら…」
こんな不安、もうありません。ブランチという並行世界で試してみて、うまくいったらマージ、ダメだったら削除。それだけです。
本番は常に安全。いつでもやり直せる。
この安心感があるからこそ、開発者は大胆な挑戦ができるんです。
そして今、あなたもその自由を手に入れました。
まとめ：一人チーム開発の第一歩
このPart 1で、あなたは以下のことを体験しました：
- スマホからClaude Codeを使ってコードを修正
PCがなくても、プロジェクトを前に進められる - ブランチという「並行世界」の自然な発生
Claude Codeが自動で作ってくれる安全装置 - プルリクエストでのレビュー
変更内容を確認してから本番に反映する流れ - マージによる統合
並行世界の変更を、本番にコピー - Manusでの同期確認
GitHubをハブとした、デバイス間の連携
これが、「一人チーム開発」の基本です。
そして、この経験を通じて、あなたはGitの最も強力な機能の一つである「ブランチ」を、理屈ではなく体験として理解しました。
次のPart 2では、さらに高度なワークフローに挑戦します。PC上のIDE（統合開発環境※Google Antigravity）を使って、より大規模な修正を行い、複数のブランチを同時に管理する、プロの開発者さながらの技を身につけていきましょう。
でも、今はひとまず、ここまでの成果を祝いましょう。
あなたはもう、時間と場所に縛られない、真に自由な開発者への道を歩み始めているのですから。
| 【Google Antigravity】クレジット消費ゼロで実現する「1テーマ→10コンテンツ」自動生成！魔法のメタプロンプトで変わるコンテンツ制作の新常識 |
|
||
|
ワンポイントTip：ブランチ名の付け方
ブランチ名は、その作業内容が分かるように付けるのがベストプラクティスです。例：fix-newsletter-links（ニュースレターのリンク修正）、feature-dark-mode（ダークモード機能追加）、update-about-page（Aboutページ更新）。Claude Codeは自動で良い感じの名前を付けてくれますが、手動で作る場合は、この原則を思い出してください。
🎭 ステージ3：時と場所を超える「一人チーム開発」という名の協奏曲
Part 2：同僚Bさん、IDEで本領発揮！(Google Antigravity編)
さて、物語の舞台は再び移ります。スマートフォンをポケットにしまったあなたは今、PCの前に座る「同僚Bさん」です。Bさんの役割は、リーダーAさんが描いた設計図を元に、より複雑で、より作り込みが必要な作業を、高機能な開発環境（IDE）を使って効率的に、そしてコストを抑えながら進めること。
Cくんが移動中に見つけた課題は、あくまで氷山の一角でした。Bさん（あなた）は、プロジェクト全体を見渡し、より抜本的な修正が必要であることに気づきます。
- ニュースレターの表示が、最新のものではなく、数も2つだけ。これではポートフォリオとして機能しない。
この課題を解決するには、単なるテキストの置換では不十分です。
Webサイトから最新の情報を自動で取得し、それを表示する――そんな少し高度なプログラミングが必要になります。
しかし、心配は無用です。私たちの手には、黒い画面（コマンドライン）を一切触ることなく、AIエージェントと自然言語で対話しながら開発を進められる魔法の杖、Google Antigravityがあるのですから。
ステップ1：Bさんの仕事場（Google Antigravity）を起動する
まずは、Bさんの聖域であるGoogle Antigravityを起動します。これは、コードを書くための高機能なエディタ（IDE）に、強力なAIエージェントが同居しているようなツールです。エージェントモードを「Fastモード」、モデルを「Gemini 3 Flash」に設定すれば、高速かつ無料でAIのサポートを受けられます。
💡Google Antigravityの使い方はこちらで徹底解説しています ↓
| 【Google Antigravity】クレジット消費ゼロで実現する「1テーマ→10コンテンツ」自動生成！魔法のメタプロンプトで変わるコンテンツ制作の新常識 |
|
||
|
ステップ2：作戦会議室（GitHub）から資料一式を拝借（Clone）
Bさんの仕事は、AさんやCくんが更新した最新のプロジェクト状態を、自分のPCに持ってくることから始まります。
これを専門用語で「クローン（Clone）」と言います。しかし、難しいコマンドを覚える必要はありません。AIエージェントに、こう話しかけるだけです。
※何でも良いので作業用の場所にフォルダを作っておきましょう。私は「GitHub」というフォルダを作りました。
※作成したフォルダはチャット欄にドラックして参照できます
GitHubフォルダ にhttps//github.com/tetumemo/tetumemo-portfolioをcloneして
エージェントは即座に指示を理解し、GitHubとの通信を開始。数秒後には、あなたのPC上に、プロジェクトの完全な複製が作成されます。
※ローカルファイルにGitHubのリポジトリがcloneされました
ステップ3：サイトの現状を確認する（プレビュー）
ここで、多くの非エンジニアが最初の壁にぶつかります。「ファイル一式は手に入れたけど、どうやってサイトの見た目を確認すればいいの？」という問題です。これも、AIエージェントに聞けば一発で解決します。
サイトがプレビューできるようにしてください。
エージェントは、サイトをプレビューするために必要な設定（ローカルサーバーの起動など）を自動で行い、準備が整ったことを知らせてくれます。
準備ができたので、いよいよプレビューを表示させます。
tetumemo-portfolio を起動してプレビューを見せて
すると、エディタの横にブラウザが立ち上がり、Cくんが修正した後の、現在のサイトの状態が表示されました。これで、変更を加えながら、リアルタイムで見た目を確認する準備が整いました。
ステップ4：AIと対話し、サイトを改造する
いよいよ、Bさんの本領発揮です。ニュースレターの表示件数を増やすという、少し複雑な修正をAIエージェントに依頼します。
tetumemo-portfolio のサイトでニュースレターのカードが2つだけした表示されていません。https//tetumemo.m-newsletter.com/から直近10本の記事を自動取得して表示させるように修正してください。
修正した内容はhttps//github.com/tetumemo/tetumemo-portfolioへ変更をコミットし、GitHubにプッシュしてください。
この指示には、「何をしてほしいか（What）」と「どうやってほしいか（How）」、そして「終わったらどうしてほしいか（After）」までが含まれています。AIはこれを正確に理解し、必要な作業の計画を立て、実行に移します。
※構造分析、サイトを調査
※リンク切れを調査してファイルを修正
エージェントは、ニュースレターサイトから情報を取得するためのコード（スクリプト）を書き、それをindex.htmlに組み込み、表示を更新するという一連の作業を自動で実行します。プレビュー画面が更新され、ニュースレターの記事が10本、美しく表示されているのが確認できます。
※ニュースレターのリンクがリアルタイムで増えている
ステップ5：Bさんの仕事の証を、作戦会議室へ（Commit & Push）
修正が完了すると、AIエージェントは指示の続きを思い出します。「変更をコミットし、GitHubにプッシュしてください」という部分です。
エージェントは、変更内容にふさわしいコミットメッセージを考え、それをあなたに提案します。
問題がなければ、承認するだけ。エージェントは自動的にコミットとプッシュを実行し、Bさんの仕事の成果を作戦会議室（GitHub）に送り届けます。
GitHub上で確認すると、Bさんが行った修正（feat: ニュースレターの記事を10件表示するように修正）が、プロジェクトの歴史に確かに刻まれていることがわかります。
ステップ6：Bさんの振り返り - より安全な開発のための「魔法の言葉」
Bさん（あなた）は、自分の仕事ぶりに満足しつつも、ふと疑問に思います。「今回はうまくいったけど、いきなり本番用のファイルを書き換えて、本当に大丈夫だったんだろうか？」
そこで、あなたはAIエージェントに尋ねてみます。
たとえばいきなりMainをいじって反映させるのはリスクがあるので、通常なブランチを切って実行すると思います。その場合、私は最初、どのように依頼すればよかったですか？
AIエージェントは、あなたのプロフェッショナルな視点に感心し、待ってましたとばかりに、より安全な開発手法について解説を始めます。
おっしゃる通り、プロの開発現場では「いきなり本番用（Main）を書き換える」のは避けるのが一般的です。もし慎重に進めたい場合は、以下のように指示していただければ完璧でした！
理想的な依頼の仕方の例
「ニュースレターの記事を10本表示するように修正してください。ただし、いきなりMainを書き換えるのではなく、新しい『作業用ブランチ』を作ってそこで修正し、最後に私に確認してからMainに統合（マージ）してください。」
なぜその方が良いのか（非技術者向けの説明）
技術的な用語を日常の言葉に置き換えると、以下のような違いになります。
- 今回のやり方（直接Main）： 「本番の掲示板」に、いきなりマジックで直接書き加えた状態です。失敗すると全員に見えてしまい、消すのも大変です。
- 安全なやり方（ブランチを切る）： 「本番の掲示板」と同じ内容を、一度「別の紙（ブランチ）」にコピーして、そこで書き換えます。
- 私（AI）が別の紙に書き直します。
- テツメモさんに「こんな感じで書き直しました」と見せます（これがプルリクエストです）。
- OKが出たら、その紙を本番の掲示板にペタッと重ねて貼り付けます（これがマージです）。
この方法なら、もしAIがとんでもない勘違いをしてサイトを壊してしまっても、影響があるのは「別の紙」の上だけ。本番の掲示板は無傷のままです。安心して修正を任せられますね。
次回から使えるフレーズ
「リスクを抑えて作業してほしい」という時は、以下の言葉を魔法の呪文のように添えてみてください。
- 「新しいブランチで作業して」 （＝別の作業スペースを作って、という意味になります）
- 「プルリクエスト（PR）を作って」 （＝変更内容をまとめた報告書を作って、という意味になります。これを見ると、どこが変わったか一目で分かり、ボタン一つでメインに反映できます）
- 「最後に私が確認してからマージして」 （＝勝手に本番に反映させないで、という意味になります）
このように言っていただければ、AIエージェントは安全なステップを踏んで作業を進めてくれます。
まとめ：一人チーム開発、それぞれの役割
ステージ3を通して、私たちは「一人チーム開発」という新しい働き方を体験しました。
- 後輩Cくん（スマホ × Claude）：移動中や外出先から、アイデアが熱いうちに素早く修正やレビューを行う、機動力のスペシャリスト。
- 同僚Bさん（PC × Antigravity）：腰を据えて、AIエージェントと対話しながら、複雑な機能追加や抜本的な修正を行う、開発の核となる存在。
この二つの役割を使い分けることで、あなたはもはや、時間と場所に縛られることはありません。そして、リーダーAさんとしてManusに戻れば、彼らの仕事の成果をワンクリックで統合し、世界に公開することができるのです。
あなたはもう、孤独なクリエイターではありません。あなたの中には、強力なAIのサポートを受けた、頼もしい「チーム」が存在しているのですから。
ワンポイントTip：Google AntigravityのようなAI搭載IDEの真価は、「黒い画面を触らなくて済む」ことだけではありません。最大のメリットは、「やりたいこと」を自然言語で伝えるだけで、その実現方法を知らなくてもAIが解決してくれる「思考のショートカット」にあります。専門家ではないあなただからこそ、その恩恵を最大限に享受できるのです。
🚀 最終ステージ：世界にあなたの作品を公開しよう！
おめでとうございます！あなたは今、ManusとGitHubを連携させ、場所やデバイスに縛られない「一人チーム開発」のワークフローを完全にマスターしました。
しかし、あなたの作品はまだ、あなたとAIしか知らない「秘密の傑作」のままです。この最終ステージでは、いよいよその傑作をインターネットという大海原に解き放ち、世界中の人々に届ける方法を学びます。
Manusでサイトを「公開（デプロイ）」する
「デプロイ」とは、開発したWebサイトやアプリケーションを、サーバー上に配置してインターネット経由でアクセスできるようにすることです。かつては専門的な知識が必要な複雑な作業でしたが、Manusを使えば、ボタン一つで完了します。
ステップ1：Manusで最新の変更を取り込む
まずは、PC（同僚Bさん）が行った大規模な変更を、Manusの環境に反映させる必要があります。
- Manusのプロジェクト画面を開きます。
- 画面右上のGitHub連携パネルに、「古いバージョン」といった通知が表示されているはずです。
- 「同期」ボタンをクリックすると、ManusはGitHubから最新のソースコードをダウンロードし、自身のプレビュー環境を自動で更新します。
プレビュー画面に最新のデザインが表示されることを確認してください。
ステップ2：ワンクリックで世界に公開
準備が整ったら、いよいよ公開です。
- Manusのプロジェクト画面右上にある「公開」ボタンをクリックします。
- 公開設定後画面が表示されます。ここで、
https://your-project-name.manus.spaceのような、あなたのサイトの公開URLが発行されます。
これだけです。数十秒後、あなたのサイトは世界中の誰もがアクセスできる状態になります。発行されたURLを友人に送ったり、SNSでシェアしたりしてみましょう！
補足：自分だけのURL（カスタムドメイン）を設定する
manus.spaceのURLでも十分に素晴らしいですが、多くの非エンジニアにとって、「自分だけのオリジナルURL」を持つことは、一つの大きな夢ではないでしょうか。例えば、tetumemo.com のようなURLです。Manusは、この夢も簡単に叶えてくれます。
ステップ1：ドメインを取得する
まずは、あなただけの「住所」となるドメインを取得する必要があります。「お名前.com」や「Google Domains」などのドメイン登録サービスで、好きな文字列のドメインを購入しましょう。（年間数百円〜数千円程度かかります）
ステップ2：Manusにカスタムドメインを登録する
- Manusの公開設定画面のドメインメニューで、既存のドメイン接続から「ドメインを接続」ボタンを選択します。
- 購入したドメイン（例：
tetumemo.com）を入力し、「確認」ボタンをクリックします。
ステップ3：DNS設定を行う
ここが唯一、少しだけ技術的な作業が必要になる部分ですが、落ち着いてやれば大丈夫です。設定は購入した会社のページに掲載されていますし、AIで確認できます。以下は代表的な方法を記載しておきますね ↓
- Manusの画面に、
CNAMEレコードという設定情報が表示されます。これは、「あなたのドメインへのアクセスを、Manusのサーバーに転送してください」という指示書のようなものです。 - ドメインを購入したサービス（お名前.comなど）の管理画面にログインし、「DNS設定」や「ネームサーバー設定」といったメニューを探します。
- Manusの画面に表示された
CNAMEレコードの情報を、そっくりそのままコピー＆ペーストで設定します。
設定が完了し、しばらく待ってから自分のカスタムドメインにアクセスしてみてください。そこに、あなたがAIと共に作り上げた美しいギャラリーサイトが表示された時の感動は、きっと忘れられないものになるはずです。
🔗ManusとGitHubの連携：開発の力を最大限に引き出す完全ガイド
💡もし、もっとGit×GitHubに興味が出てきたら…あきらパパさんの「Git & GitHub完全入門ガイド」がオススメです！
📕あきらパパさんの「Git & GitHub完全入門ガイド」が素晴らしすぎました...！
@tetumemo
これ、エンジニアの方はもちろんですが、個人的には「AIを使って何か作りたい非エンジニア」の方にこそ全力でおすすめしたいです
なぜなら、Gitを理解することは、Vibe… https://t.co/8lgJ5GR71Kpic.twitter.com/wZVgTnJIDd— テツメモ｜AI図解×検証｜Newsletter (@tetumemo) January 4, 2026
ワンポイントTip： DNS設定がインターネット全体に反映されるまでには、数分から最大で72時間程度かかる場合があります。設定後すぐにアクセスできなくても、焦らずに待ちましょう。
💡ここからのコンテンツ：🚧 「わかった」と「できる」の間にある、あの谷
ここまで読んでくださって、ありがとうございます！
GitもGitHubも理解できた。セーブポイントの威力もわかった。
でも、正直に言いましょう。
今、こんな声が聞こえてませんか？
「理屈はわかった。でも…本当に一人でできる？」
「クレジット使って失敗したら、もったいなくない？」
この感覚、めちゃくちゃわかります。私も最初、マウス持つ手が震えてましたから。
YouTubeの料理動画、あるあるですよね
見てる時は「簡単そう！」って思うのに、実際作ってみたら全然違う味になる。
知識と実践の間には、想像以上に深い谷があるんです。
でも、想像してみてください。
3ヶ月後のあなたが、電車の中でスマホをサッと開いて、「あ、ここ直したい」と思った瞬間に修正。家に帰ってPCで確認したら、完璧に同期されてる。そして「まあ、失敗しても戻せるし」と涼しい顔で実験を楽しんでる。
この未来、手に入れたくないですか？
🎁 有料エリアで待っているもの
単なる復習じゃありません。本編より実践的な、リアルなワークフローを体験できます。
こんなあなたに
✅ 理論はわかったけど、一人でやるの怖い
✅ クレジット気にせず、心ゆくまで試行錯誤したい
✅ どんな場所からでも開発できる自由が欲しい
解決できること
- クレジットの呪縛から解放
今回はPC（Google Antigravity）から開始。何度失敗してもクレジットは1ミリも減りません。「もったいない」から解放された瞬間、創造性が爆発します。 - ツールを使い分ける力
Manusから、PCから、スマホから。状況に応じて最適なツールを選べるようになります。これが「使いこなす」ということ。 - 失敗への恐怖が消える
実際にサイトを作り、ブランチで実験し、意図的に壊し、涼しい顔で戻す。この体験が、恐怖を完全に消します。
作るもの
🔗 【完成見本】🍌 Nano Banana Prompt Gallery
Manusを使わず、無料でサイト公開まで。本編より少し複雑ですが、だからこそ「本当に作れるんだ」という実感が得られます。
ドリルを終えたら、別人になってます
- AIの気まぐれに怯えない
- 失敗を「学び」として楽しめる
- 「自分、意外とできるじゃん」を実感
この実践ドリルは、あなたの「知識」を「体得」に変える、最後のピースです。
知識だけ持って帰っても、結局使わなくなる。でも一度でも「できた！」を体験すれば、それは一生モノのスキルになります。
さあ、3ヶ月後の自分に聞いてみてください。
「あの時、やっておけばよかった」と思うか。
「あの時、やってよかった」と思うか。
答えは、もう出ているはずです。
| 購読中 |
📝 発行者
🎤Spotify：AI QUEST（今日から始めるAI生活）
🎤Apple Podcasts：AI QUEST（今日から始めるAI生活）
📹️YouTube：AI QUEST（今日から始めるAI生活）
📝noteでも、たまにAIなどの記事を書いています。
🎟️お得な招待コード
💡Manus（1,000クレジットが獲得できる限定招待コード）
💡AIエージェント「Felo」（月額100円引きの招待コード）
💡Perplexity Pro（初月10ドルの招待コード）
💡リアルタイム翻訳「Felo字幕」（15分無料で試せる招待コード）
| ここから先は有料コンテンツです |
| |
| この続き：11194文字 / 画像71枚 |
7,000人以上の方達が購読中
いつでも購読解除可能です