ChatGPTに自分のサーバーをつないだら、AIの使い方が変わった

「ChatGPTは便利だけど、結局は文章を書いてもらう道具だよね」

少し前まで、私の中でもその感覚が強くありました。

もちろん、文章を書く、相談する、コードのたたき台を作る。そうした用途だけでも十分に便利です。

ただ、自分のサーバーと接続して使うようになってから、その印象は大きく変わりました。

ChatGPTそのものの知能が急に上がったわけではありません。それでも、AIの使い方そのものが変わったという感覚があります。

以前、構成や開発の記録は「非エンジニアがChatGPTとVPSで『自分専用AI基盤』を作ってみた」にまとめました。この記事ではその続きとして、実際に使い始めて何が変わったのかを書きます。

これまでのChatGPTは「考えるところ」までだった
サーバーとつないだら、できることの質が変わった
AIに「手足」が付いた感覚
実際に変わったこと
「AIを使う」から「AIを組み込む」へ
もちろん、万能になったわけではない
前の記事と今回の記事の関係
いま面白いのは、能力そのものより「つなぎ方」
最後に
追記：開発の経緯は正式連載で整理しています

これまでのChatGPTは「考えるところ」までだった

以前のChatGPTは、基本的には「考える」「書く」「提案する」ところまでを担当していました。

たとえば、

記事の構成を考える
コードのたたき台を作る
データ解析の方針を相談する
SNS投稿文の案を出す

といった作業です。

十分便利でしたが、その先にはいつも人間側の作業が残っていました。

コードを書いてもらっても、実際に動かすのは自分。記事案を作ってもらっても、WordPressへ入れるのは自分。 SNS文を考えてもらっても、各サービスへ投稿するのは自分。

ChatGPTは優秀な相談相手ではあっても、実作業との間にははっきりと境界がありました。

この「コードを書いてもらっても、人間がSSHとコピペの運搬係として残る」問題は、正式連載の第2回「ChatGPTにコードを書かせるだけでは足りなかった。Development MCPを作った」で詳しく書いています。

サーバーとつないだら、できることの質が変わった

この境界が変わったのは、ChatGPTからMCP経由で自分のVPSへアクセスできるようになってからです。

サーバー側には、Linux、Python、Git、データベース、n8n、WordPress連携、SNS連携などを少しずつ積み上げてきました。

その結果、会話が単に「案を出して終わり」ではなくなりました。

コードを書き換える
テストを実行する
データを保存する
長めの処理を走らせる
WordPressの記事を準備する
XやBluesky、Instagramの投稿を準備する

こうしたところまで、一連の流れとしてつながります。

特にDockerのbuildや再起動、長時間処理をDevelopment Runnerという別の実行面へ分けたことで、「AIとの会話が終わること」と「サーバー上の仕事が終わること」を切り離せるようになりました。この経緯は第3回「AIに自分自身を再起動させたら止まった。Development Runnerを分離した」にまとめています。

この考えはさらにLoop Engineで、ChatではなくRunを仕事の正本にし、Event / Checkpoint / pause / resumeとして状態を残す形へ発展しました。ブラウザやサービスが途中で切れても、別のChatからlive stateを読み直して続きを始められます。

→ 第7回：AIが途中で止まっても、続きを再開できるようにした

重要なのは、AIが突然なんでもできるようになったわけではないことです。

ChatGPTの外側に「記憶」「計算」「実行」「公開」の仕組みを作り、その仕組みを会話から使えるようにした。

そう考える方が正確です。

AIに「手足」が付いた感覚

この変化を一言でいえば、私にとってはChatGPTに手足が付いた感覚に近いです。

以前は、

相談はChatGPT
実行はサーバー
記録は別の場所
公開はWordPressやSNS

と、道具を持ち替える必要がありました。

今は、会話の中で考え、必要なら計算し、ファイルへ残し、出力を確認し、修正し、そのまま発信まで進められます。

もちろん、最後の判断や承認は人間が持ちます。ただ、途中の反復作業はかなり任せられるようになりました。

この「最後の判断は人間、途中の反復はAI」という分担も、その後はもう少し細かく整理しました。安全で可逆でscopeが決まったroutine作業なら、毎回「承認します」で止めず次の本当のprotected boundaryまで進める。一方、secret、root、不可逆なproduction操作、目的変更などは人間へ残す。Standing Delegationで、人間を消すのではなく、人間が本当に判断すべき場所だけを残す形へ変えています。

→ 第10回：AI開発のたびに「承認します」と打つのをやめた

そして、その本当に人間が必要な境界では、承認そのものを消さずに入力だけを軽くしました。ChatGPT上のApproval UIはOwner intentを送るだけで、Authority・policy・live-state再検証はサーバー側に残しています。

→ 第11回：AIに「承認」ボタンを作った。でも、ボタンに権限は渡さなかった

実際に変わったこと

「相談」で終わらず、処理まで進む

以前なら、「こういう解析がしたい」と相談したあと、自分で環境を開いて実行する必要がありました。

今は、会話の流れの中で処理まで進められる場面が増えました。

地味ですが大きい。思考と実行の間にある摩擦が減るからです。

情報がその場限りで終わりにくい

ChatGPTとの会話は、その場では便利でも後から埋もれやすいです。

サーバー側にMarkdown、データベース、履歴管理を持たせることで、記録として残し、後から検索し、別の作業へ再利用できるようになりました。

単に会話するAIではなく、少しずつ「自分用の知識基盤」の一部になっています。

長期記憶側の出発点は、正式連載の第1回「ChatGPTに長期記憶が欲しくて、Knowledge MCPを作った」にまとめています。

発信までの距離が縮まった

ここはかなり面白いです。

「ChatGPTから外部サービスに投稿できるようになって面白い」という内容を、実際にChatGPTから外部サービスへ投稿する。

少し入れ子ですが、以前の使い方にはなかった一体感があります。

この発信経路をn8nの固定workflowではなくPublishing MCPへ分け、Publication、revision、preview、read-back verificationを持たせた経緯は、第5回「記事を書くだけでは自動化にならなかった。Publishing MCPを作った」で整理しています。

新しい用途を後から足しやすい

今の環境は、一つの専用システムを作って終わりではありません。

研究データ解析、WordPress投稿、SNS配信、動画編集、音声文字起こし、知識整理。一見ばらばらでも、

ChatGPTが判断する → サーバーが処理する → 結果を保存する → 必要なら公開する

という同じ流れに乗せられます。

ここが単なる便利ツールの寄せ集めとは少し違います。

ただ、能力を後から足しやすくなったことで、次に別の限界も見えました。Knowledge、Development、Publishingと「できること」が増えても、次にどの能力を使い、何をすべきかを決めるのは毎回人間のままだったことです。

そこで既存MCPを置き換えず、その上にGoal → Plan → Execute → Evaluateを回すLoop Engineを追加しました。

→ 第6回：MCPをいくつ作っても、AIは自律化しなかった。そこでLoop Engineを作った

さらに使い続けると、「自動で動く」と「自律的に考える」も別だと分かりました。手順が決まっている仕事を毎回LLMに考えさせる必要はなく、そうした仕事はWorkerへ降ろす。一方、GoalとSuccess Criteriaを持ち、Evidenceを見て次の一手を変える仕事だけをLoopへ載せる。この区別が現在の運用の基本になっています。

→ 第8回：作業自動化と「自律するAI」は何が違うのか

そして複数のChatGPTを同時に動かすようになると、「能力のつなぎ方」に加えて仕事同士の調整が必要になりました。別々のWorkspaceで作業を分離し、sharedなmerge/deployは直列化し、別ChatのWorkspaceは見えても勝手には継続しない。モデルを増やすだけではチームにならず、coordination layerが必要だったという変化です。

→ 第9回：複数のChatGPTに同じシステムを開発させたら、普通に衝突した

「AIを使う」から「AIを組み込む」へ

最近いちばん変わった感覚は、ここかもしれません。

以前は、必要な時にChatGPTを開いて使う感じでした。

今は、ChatGPTを単独のサービスとして使うというより、自分の作業環境の中へAIを組み込んでいる感覚があります。

相談相手。実行系の入口。情報整理の窓口。発信作業の中継点。

ChatGPTが「外部の便利な道具」から「自分の環境の中で働く頭脳」に少しずつ近づいています。

もちろん、万能になったわけではない

ここは分けて考える必要があります。

サーバーと接続しても、ChatGPTは間違えます。仕様の理解が甘いこともあります。実行すべきでない処理は止める必要がありますし、最後の公開判断や品質判断も人間が持つべきです。

むしろ、こうした環境では、どこまで任せて、どこで人間が止めるかの設計が重要になります。

Docker操作のような強い権限を日常的な開発入口から分離したのがDevelopment Runnerです。AIが変更を作ることと、その変更をmainへ採用することを分けたのがGitHub Pull Request。記事を作ることと、公開することを分けたのがPublishing MCPです。

頭脳だけでなく、記憶、計算、作業環境、公開経路まで揃うと、同じAIでも到達できる成果物のレベルが変わります。

第8回で整理したbounded autonomyもこの延長です。自律化は権限を無制限に広げることではなく、Goal・Capability・risk・budget・approval boundaryで「安全に選べる範囲」を作ることでした。

第9回ではさらに、複数AIを同時に動かすなら「誰がどの仕事を進めてよいか」まで外側の設計に含める必要があると分かりました。

そして第10回では、境界を残しつつも、routineな承認往復を減らしました。毎回人間へ戻すのではなく、機械で確認できる安全・可逆な処理は続け、人間の承認をprotected boundaryへ集中させています。

→ 第10回：AI開発のたびに「承認します」と打つのをやめた

その先の第11回では、残った人間判断を軽くするApproval UIを追加しました。便利なUIと実行権限を同じものにせず、押された意思と「今実行してよいか」を別レイヤーで扱っています。

→ 第11回：AIに「承認」ボタンを作った。でも、ボタンに権限は渡さなかった

前の記事と今回の記事の関係

前回の記事が「どう作ったか」の記録なら、今回は「作った結果どう変わったか」の記録です。

前回：構成、失敗、改善、実装
今回：実際の使い方、感覚の変化、運用

「そもそもどういう構成でつないでいるのか」が気になる場合は、先に前回の記事を読むと分かりやすいと思います。

いま面白いのは、能力そのものより「つなぎ方」

生成AIの話では、「どのモデルが賢いか」に注目が集まりやすいです。

もちろん重要です。

ただ、実際に使っていて強く感じるのは、AIの性能そのものだけでなく、何につながっていて、どこまで動けるかも同じくらい重要だということです。

どれだけ賢くても、考えたことを実行できなければ、最後は人間が全部つなぐ必要があります。

一方で、ある程度賢いAIに、記憶、計算環境、実行基盤、外部サービスとの接続が加わると、使い方そのものが変わります。

「便利になった」より、仕事の流れが変わった、の方が近い。

そして現在は、その「つなぎ方」自体をLoop Engineで仕事の流れとして扱い始めています。Capabilityを増やす段階から、Capabilityをどう順番に使うかを設計する段階へ移った形です。

最後に

自分のサーバーとつないで分かったのは、ChatGPTが急に別物になったわけではない、ということでした。

それでも、AIの外側にある仕組みを整えることで、AIの使い方は大きく変わります。

個別の作業をその都度頼むのではなく、自分の作業環境全体の中にAIを少しずつ組み込んでいく。

いま起きている変化は、たぶんそこです。

そして何より、

「次は何をつなげたら、もっと面白くなるだろう」

と考えられるのが楽しい。

ちなみに、この記事の作成と投稿準備もChatGPT上で進めています。

こうしたこと自体が、すでに以前とは違うAIの使い方なのだと思います。

追記：開発の経緯は正式連載で整理しています

この記事は、Personal AI Platformを実際に使い始めて何が変わったかを中心にした体験編として残します。一方、Knowledge MCP、Development MCP、Development Runner、GitHub PR、Publishing MCP、Loop Engine、Run / Checkpoint / Resume、Autonomous Loop、Parallel Chat / Workspace、Standing Delegation、Approval UIがなぜ必要になったのかという開発史は、正式連載「ChatGPTと育てる、自分専用AI基盤」で順番に整理しています。