PoCの全体像は、Proof of Concept（概念実証）ページ にまとめています。そこで書いたのは「アプリを作り始める前に、開発基盤を先に整えていた」という話の輪郭でした。この記事では、その基盤を実際にどう組み立てたのか、どう考えて、何を試して、何を変えていったのかを書き残しておこうと思います。
最初に明確にしておくと、私は、元々開発者のキャリアがありません。長くITエンジニアの領域にいて、様々なシステムを扱ってきましたが、トラブルシューティングのためにコードを書くぐらいで本職ではなかったです。それでも、生成AIとMCPを軸に、この7ヶ月で7つ以上の仕組みを内製で立ち上げることができました。
なぜそれが可能だったのか。ひとつには、AIと一緒に開発する環境を、本格的に整えてみた ことが大きかったと思っています。GitHubの上手な使い方も、多くはClaudeに聞くところから始まりました。「開発者ではないから諦める」ではなく、「開発者ではないから、AIに相談しながら整えていく」スタイルを選んだ、というだけの話です。
この記事では、その環境を組み立てる過程で、私が何を考えていたかをご紹介します。
手元にあるものから始めた
始まりは、大きな改革ではなく、日常の中の小さな関心からでした。
Claude Desktopを使うたびに、毎回、資料を添付するのが面倒だと感じていた。それと同時に、AIから自社のデータやツールへ、決められた形で繋げられるAPI（プログラム同士を繋ぐ窓口のようなもの）が欲しいとも考えていました。「AIに手足をつけて、社内の情報を直接扱わせたい」——このイメージに、当時ちょうど公開されはじめていたMCPという仕組みがぴったり合っていた。この不便と願いを解消するために、自宅LAN内にMCPサーバーの原型を立ててみようと考えました。
手元には、コロナ禍から使っていたPCが2台ありました。ひとつは仕事用に用意したリモート会議用ハイスペックなデスクトップ機、もうひとつはVR用に用意したグラフィックボード付きの機体。どちらも、当時の利用用途にはもう十分すぎるスペックでした。
「使っていないなら遊ばせず、この機体をサーバー化しよう」——そう考えたのが、SawaLeafの開発基盤の出発点です。デスクトップ機を自宅LAN内アクセスのサーバーへ据え直し、もう1台をメインのWindows機として整理する。役割を分けただけの再配置 から始めました。まずは、自宅にあるもので小さくPoCを始めてみた、という感じです。
使ってみて、不便なら構成ごと変える
サーバー化した最初のフェーズでは、Windowsホストの上でDocker Desktopを動かし、その上でMCPの原型を動かしていました。Claude Desktopで相談したブログ記事をウェブサーバー（WordPress）に投稿できたり、視聴者の推移をGA4のデータで確認する”原型”が、この時期に動き始めています。
ただ、この時期はまだ、SawaLeafの開発基盤としては形になっていませんでした。SawaLeafが契約しているConoha上のWordPressは共有環境で、そこにウェブアプリを直接載せられません。そこでAzure上に別途ウェブアプリを立てて、WordPressと連携させることで、AIを組み込んだチャットボットやアセスメントツールなどを制作して試していました。開発環境自体が、まだ試行錯誤の途中 だった時期です。
やがて、この構成の中間層のオーバーヘッドが気になってきました。Docker Desktopは、実は内部でWSL2（Windows上でLinuxを動かす仕組み）を使っていて、実質的には「Windows → Docker Desktop → WSL2 → Dockerエンジン」の4層構造で動いている、いわゆる重い状態でした。Dockerを使うか、WSL2を使うかの二者択一ではなく、「Docker Desktopという中間層を残すか、外すか」の判断 だった、というのが今思うと分かりやすい整理です。
そこで、10日間で段階的に構成を組み替えていきました:
- Docker Desktopを外し、WSL2上に直接Dockerエンジンを載せる形（3層構造）へ
- WSL2自体もやめて、Ubuntu Serverをホストごと動かす形（2層構造）へ
層を1つずつ剥がしていった ような移行だったと言ってもいい。一気にUbuntu化しなかったのは、当時まだ、Claude Desktop、ブラウザ、Teams、RDPなどWindows側にGUI依存の作業が残っていて、いきなり全部を手放す踏ん切りがつかなかったからです。「Windowsを残したまま、少しずつLinuxネイティブに寄せる」中間解を通した、という感覚です。
そして最終的に、Ubuntu Server本体への切り替えを決めた理由は3つありました:
- パフォーマンスを上げたい
- 専用機化し、無駄な機能を減らすことで、余計なトラブルに巻き込まれないようにしたい
- LAN内の他のPCからも、同じようにMCPを利用できる形にしたい
一人でこの判断を下すのは、正直、なかなか怖い作業です。バックアップを取って、さら地からLinux環境を組み直し、必要なコンポーネントを復元する——このすべての進行を、Claudeがサポートしてくれました。「とりあえずやってみて、ダメなら変える」を、AIに相談しながら10日間で回せた。AIに相談しながら回せるからこそ、”変える” という選択のコストが下がる ——この感覚は、後になって効いてくる大切な発見でした。
もうひとつ、この時期に気づいたことがあります。「変えるべきところは変える、残せるところは残す」の判断です。Ubuntu化のあと、n8nはCoreのDocker Composeから外して、ホストで直接動かす形に切り替えました。一方で、Amplifier MCPとHome MCPは今もDockerのままです。“すべて統一する” ではなく、”用途ごとに最適を選ぶ” ——この判断ができるようになったのも、構成をゼロから組み直した経験があったからだと思います。
全部任せると、逆に不安定になる
Ubuntu化を機に、Claude CodeをUbuntu機に直接載せる形に切り替えました。それまではクラウド上のClaude Codeを使っていましたが、開発サーバーの中で直接動かせるようにすることで、「Linux上でもっと攻めのある開発にシフトしていこう」という判断です。
ただ、この時期、Claude DesktopとClaude Codeの役割分担はすぐには決まりませんでした。すべて任せてしまうと、時間がかかり過ぎたり、状況判断が良く見えないことがあった。良かれと思って進んでやってくれたのが、別の問題を発生させることもありました。
たとえば、新しいコンポーネントを入れる際、サンプルの .env.example に引っ張られて、既存の .env を上書きしてしまう事故が何度か起きました。.env には Google などのクレデンシャル情報が保管されていたので、そのたびに取り直しになる。Claude 側にRULES.mdなどで「上書きしないで」と伝えても、状況によっては同じ失敗を繰り返すことがある。最終的には、権限管理で物理的に守る形に切り替えることになりました。
“口で伝えるだけでは、AIとの分業は安定しない” ——この気づきの起点が、この事件でした。
そこから、相談するドメインを分けること、役割を決めること が、AIと働くうえでの安定した活用のポイントだ、ということが見えてきました。全部任せる、ではなく、Claude Desktopには相談する、Claude Codeには実装を委ねる。どこで判断を挟むかを明確にする。この気づきをどうAIとの分業の型に落とし込んだかは、シリーズ次回以降の記事でじっくり書きます。ここでは、「Claude Codeを開発サーバーに載せた直後、役割分担の再設計が必要になった」という気づきの起点だけを残しておきます。
分けようとしたのではなく、用途で自然に分かれた
sawaleaf-amplifier、sawaleaf-home、sawaleaf-core——SawaLeafには現在、3つのMCP基盤があります。しかし、これは「3本に分ける」と決めて設計したものではありません。用途に応じて、自然と分岐していきました。
「GA4とWordPressのデータを分析したい」から始まったのが Amplifier。太陽光発電やSwitchBotの連携が育ってきたとき、「これはウェブ運用とは別軸だな」と自然に感じたところから Home が分離。n8n連携や横断ハブの役割で、最後に Core が生まれる。「これはこっち、あれはあっち」と、必要が来るたびに分かれていった 結果、この3本立てになっています。
分けたことで、MCPに載るツールが増えても、認知の負荷が抑えられました。ひとつのMCPに全部詰め込んでいたら、たぶん今のスピードでは動けていなかった気がします。
同じ「結果として現れた」パターンが、ルール管理でも起きました。各リポジトリに CLAUDE.md（Claudeへの指示ファイル）が増えるにつれ、同じ内容が違うファイルに書かれ、更新が追いつかなくなる。そこで、sawaleaf-core/docs/SAWALEAF-RULES.md を「真の情報源をひとつだけ持つ」形として据え、各リポジトリのCLAUDE.mdはそこを参照するだけの形に変えました。
そして、このRULES.mdに 「失敗パターンを蓄積する」 ようにしています。運用の中で見つかった問題や、AIとの分業で起きた事故は、原因と対策をRULES.mdに書き足す。次に同じ状況が来たときにAIがそれを参照するので、同じ失敗を繰り返さない構造になっています。
これも、設計ではなく発見でした。動かしながら不便を感じたところから、次の型が生まれる ——このパターンが、SawaLeafの開発基盤の作り方の芯だったのだと、今では思います。
開発者ではないから、AIに聞きながら整える
ここまで見てきたのは、大きく分けると3つの気づきです:
- 使ってみて、不便なら構成ごと変える — AIに相談しながら回せば、”変える” のコストは下がる
- 全部任せると、逆に不安定になる — 相談するドメインを分ける、役割を決める
- 分けようとしたのではなく、用途で自然に分かれた — 設計ではなく発見
これらは、最初から設計思想として持っていたわけではありません。動きながら気づいた、事後的な原則 です。開発者ではないからこそ、教科書的な「正しい設計」に縛られず、AIに聞きながら、必要が来たら変える、というスタイルで整えられたのかもしれません。
もうひとつ、AIと相談しながら進めた大事な理由があります。新しい機能や技術が出てきたときに、「これを SawaLeaf で使うなら、どんな使い方がある？」を、その場で相談できることです。技術トレンドの追いかけを、教科書や記事から情報を集めて自分で判断する、という形ではなく、“AI と対話しながら、自分たちの環境に落とし込む形を一緒に考える” ができる。これは、開発者ではない立場だからこそ、より価値の高い進め方だと感じています。
そして、これがおそらく最も大事な学びなのですが、環境が整った瞬間から、その上に何かが動き出せるようになる ——このことが、実際に起きました。基盤を組み立てるまでのあいだ、SawaLeaf の 「AI エージェント」——番頭・クラ番・アジ番・ハンナ・Insight Radar・電力の見立てといった “番シリーズ” ——は、まだ1本も動いていませんでした。環境を整え終えた瞬間から、これらが順に立ち上がっていきました。
最初に整えたから、余計なことを考えずに済む、次のことに集中しやすい環境が作れた ——このことは、このシリーズの他の記事を読むときにも、頭の隅に置いてもらえると、話が繋がりやすいと思います。
▼ 参考：時系列と構成の詳細
読み手の中に「日付や構成の具体は？」と気になる方もいらっしゃるかもしれないので、詳細をリストで残しておきます。
時系列（2025年秋〜2026年3月）:
- 2025年秋: 既存PC2台の役割再配置。デスクトップ機をLinuxベースのMCP/n8n用サーバーへ。もう1台をメインWindows機として整理
- 2025年秋〜11月: Windows + Docker DesktopでMCPの原型を動かす（GA4連携、WordPress投稿）。並行して、Azure上でWordPressと連携するウェブアプリ（サワモト メソッド関連のチャットボット、アセスメント）を試行錯誤
- 2025年11月27日: Git管理を開始。「AIにコードを書いてもらう保管場所」の必要性から
- 2025年12月: 3リポジトリ並行で始動、1ヶ月で約50コミット（Amplifier 22 / Home 24 / Core 5）
- 2026年2月上旬: Docker Desktopをやめて、WSL2上に直接Dockerエンジンを載せる構成へ（4層 → 3層）
- 2026年2月中旬〜下旬: WSL2運用の限界に直面（Windows側との二重管理コストが想定以上）
- 2026年2月26日: Ubuntu Server本体への移行を完了（3層 → 2層）
- 2026年3月1日: n8nをDockerからネイティブ実行（systemd user service）に切り替え。Core MCP本体もネイティブ化
- 2026年3月: Claude CodeをUbuntu機に直接載せる形に切り替え。
.env上書き事件などを経て、役割分担の再設計へ - 2026年3月後半: SAWALEAF-RULES.mdによるルール一元化
現在の技術構成:
| 用途 | 構成 |
|---|---|
| 開発サーバー | 自宅LAN内・Ubuntu Server 24.04 |
| AIとの対話環境 | Claude Desktop（方向づけ）+ Claude Code（実装） |
| MCP基盤 | 3系統: Amplifier（ウェブ運用）/ Home（自宅アプリ）/ Core（横断ハブ） |
| 自動化基盤 | n8n（業務ワークフローの自動化） |
| ルール管理 | SAWALEAF-RULES.md を単一の正として運用 |
| リポジトリ管理 | GitHubで一元化（2025年11月〜、内製） |
▼ 用語メモ
本文の中に出てくる、少し馴染みが薄いかもしれない用語を、簡単に説明しておきます。
- API（Application Programming Interface）: プログラム同士が情報をやり取りするための窓口。「このURLに、こういう形でリクエストすれば、この形式のデータが返ってくる」というルールをあらかじめ決めておくことで、外部のツールやサービスと連携できます。MCPは、AIがこのAPIを扱いやすくするために標準化された仕組みです
- MCP（Model Context Protocol）: 生成AIが、外部のデータやツールを扱えるようにするための共通の仕組み。「AIに手足をつける」ためのオープン標準として、2024年11月にAnthropicが公開しました。その後OpenAI、Google、Microsoftも採用し、2025年12月にはLinux Foundationへ寄贈され、業界共通のインフラになりつつあります
- Docker / Docker Desktop: アプリケーションを「箱（コンテナ）」に分けて動かす仕組み。1台のPCの中に、独立した複数のアプリを整理して並べられます。Docker Desktopは、Windows上でこの仕組みを使えるようにするデスクトップ製品
- WSL2（Windows Subsystem for Linux 2）: Windows上でLinux環境を動かす、Microsoft公式の仕組み。Linux専用のツールを、Windowsを使ったまま試したいときに便利
- Ubuntu Server: Linuxの一種で、サーバー用途に最適化されたバージョン。画面操作（GUI）が最小限で、他のPCからネットワーク越しに管理する形が基本
- n8n: 「AがあったらBを実行する」というワークフローを、コードを書かずに組める自動化ツール。定期実行や、外部サービスとの連携を担います
- Claude Desktop / Claude Code: どちらもAnthropicが提供する Claude というAIを使うためのツール。Desktopは対話型のアプリで、方向づけや相談に使う。Codeはターミナル上でコードを書かせる、開発作業向けのツール
.envファイル: プログラムから使う「環境変数」を、テキストファイルとして保管するもの。APIキーやパスワードなどの認証情報（クレデンシャル）を、コード本体とは分けて置く場所として使います