> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2026/w41-personal-ai-practice-tools-engineering-and-runtime-environments.md).

# W41-Side Projectの振り返り：ツール、工程、ローカルとクラウドの選択

2026年10月10日 · 10月13日改訂

中秋節と国慶節の連休に、金山嶺の阿那亜へ行った。家族旅行に向いている場所だった。帰ってからも数日余裕があり、休み明けの最初の週もそれほど忙しくなかったので、やりたかったことを少し進めた。

振り返ると、先週はかなりいろいろなことをした。AIの実行環境の管理、家庭財務のエンジニアリング、長年使ったサブスクリプション管理ソフトの置き換え、ネットワークプロキシの信頼性改善、自分のメディアの自動化フロー。これらを並べると、この1年のAIの使い方も見直すことになった。

以前、個人の用事をエンジニアリングの対象にする話を書いた。それらに実データを入れ、実アカウントにつなぎ、継続して動かそうとすると、今まであまり気にしていなかった問題がいくつも現れた。

## AI実行環境の保守

私のMac Studioは会社に置いてある。帰宅後や週末には、遠隔で作業させることが多い。国慶節の旅行に出る前、このマシンが十数日間使える状態を保ち、外出先からいつでも呼び出して、やりたいことを任せられるか試したくなった。

結果は、2、3日でうまくいかなくなった。その間にClaudeとOpenAIのモデルが更新され、一部のクライアントは手動更新が必要だった。期限切れのログイン状態は再認証が要り、Chromeの自動操作に依存するタスクもあり、メモリの整理も必要だった。個別には小さな問題だが、外にいると、1か所止まるだけで後の作業を続けられない。

そこで帰宅した初日、かなりの時間を使って環境を整理し、休み中のモデルの進展も確認した。

**電源が入り、ネットワークにつながっているだけでは、この作業環境をいつでも使えるとは限らない。**

この経験から、AI runtimeの日常管理タスクを追加した。1つは各ツールに設定されたモデルを確認し、同系列のモデル更新を追うこと。もう1つはCodex、Claude Code、Geminiなどのランタイムの版を確認し、設定とツールの版が徐々にずれるのを減らすことだ。

以前は問題が起きてから処理することが多かった。今は同時に頼るAIツールが増え、保守も定常的な仕事になり始めた。特に遠隔利用では、手元なら少しクリックして済む認証や更新が、実際の作業停止にまで膨らむ。

## 家庭財務データのエンジニアリング

家庭財務の取り組みは以前も触れ、基礎はすでに作っていた。今回は4、5日をかけ、主にClaudeで集中的に進めた。およそ8割までできたが、最初の見込みより明らかに時間がかかった。

やりたいのは、家庭全体の財務状況を継続して維持できる仕組みに収め、分析、監視、振り返りの根拠、必要に応じたグラフ作成に使うことだ。実際に始めると、グラフと分析は一部にすぎず、その下のデータとルールが大部分を占めると分かった。

たとえばプライバシーでは、最初は金額を隠すことを考えやすい。だが細かく見ていくと、保有口数も気軽には公開できない。公開されている基準価額を掛ければ時価を逆算できるからだ。比率も、ほかの情報と組み合わせると、公開するつもりのない内容を明かしてしまう。単独の項目では機微性が低く見えても、組み合わせるとまったく違う。

データの正確さもそうだ。いつ発生し、いつ入力されたのか。実際の観測値か、計算値か、推計値かを分けて記録する必要がある。古い記録を訂正する場合も、単純に上書きせず、訂正関係を残す。情報源の取得に失敗したら、見かけだけ完全な結果を作ってはならない。欠損値をゼロで埋めてもいけない。

こうした制約は、最終的にプログラムへ落とす必要がある。現在はコミット前に、リポジトリへ入る内容を検査し、ファイルそのものの形式も識別する。拡張子だけ変えた元の表計算ファイルを、誤ってコミットしないためだ。プロンプト上の要件にはプログラムの支えが要る。なければ、毎回モデルが十分に覚えていることに頼るしかない。

最初には思いつかず、Claudeと繰り返しレビューするうちに見つかった問題もある。後半は境界を探り、検証を足し、再レビューすることに多くの時間を使った。個人プロジェクトでも、実際の家庭データを扱うなら、利用者が少ないことを理由に省けない作業だ。

今後この仕組みに期待することは具体的だ。四半期ごとの更新で反復作業を減らし、前回と今回がなぜ違うのかを説明でき、結論がどこから来たのかも分かるようにしたい。

**事実をきちんと維持すれば、分析や可視化はいつでもやり直せる。**

## 複数端末で使うサブスクリプション管理ツール

対照的に、サブスクリプション管理ソフトはすぐにできた。今回は、低コストで自分の習慣に強く合わせ、複数のプラットフォームで使え、ネイティブアプリに近い体験を持つ小さなツールを作れるか試したかった。

まず古いソフトの登録情報を画面録画し、ChatGPTに移行用データを抽出させた。ここにも細部がある。実際に開いて詳細を表示した、現在も継続中の契約だけを残した。通貨も確認が必要で、Google Oneは台湾ドル、通信契約はマカオ・パタカだった。このような基本項目が間違えば、その後どれほどきれいに計算しても意味がない。

次に、画面、同期、配置を作った。ツールはChatGPT Sitesに置き、同サービスのデータベースを使い、スマートフォン、PC、Macで開けるようにした。iOSではWeb Appとして使っているが、実際の体験は予想よりかなりよかった。

改善の流れも単純だ。画面に期待と違う部分があれば指摘し、少しテストし、要望を補い、調整を続ける。自分だけが使い、機能の境界が明確な小さなツールには、この作り方が合っている。

こうして、長年使った管理ソフトが置き換わった。既製品を買うと、自分の好みに合わない整理の仕方も受け入れる必要があった。今は自分の習慣に合わせて作れ、変更費用も低い。万人向けの製品にする必要はない。私のこの用事をうまく片づければ、それだけで価値がある。

**Web Appという形も、改めて見直すことになった。軽量なツールや生産性向上の製品なら、Webページ、ホスティング、データ保存を組み合わせるだけで、かなり完結した体験を作れる。Scriptableのようなアプリを併用すれば、スクリプトでシステム通知やホーム画面のウィジェットを補い、Web上のデータをスマートフォンの日常の入口に届けられる。**

サブスクリプション管理のような用途なら、Web Appに少しネイティブ機能を補うだけで、低コストで高度に個別化した、ネイティブに近い体験が作れる。個人の道具1つのために、最初から複数のクライアントの開発と保守を抱える必要はない。

## ネットワークプロキシの信頼性改善

さらに1、2日は、主にネットワークプロキシの信頼性に使った。

今は仕事や生産性のツールの多くが、国外のインターネットに依存している。提供元が断続的に使えなくなるだけで、開発、調べ物、モデル呼び出しが一緒に影響を受ける。何度か止められ、真剣に扱うべき問題だと思った。

プロキシ設定の仕組みを引き続き改善し、自前の台湾ノードを最優先、商用回線Aの台湾ノードを第一の予備、商用回線Bの台湾ノードを最後の候補にした。AIの通信は台湾だけを通し、中国国内、社内、プライベートネットワークの通信は従来のルールで直接接続する。予備経路を明確にしつつ、1つのツールを動かすためにマシン全体の通信を同じ回線へ寄せることを避けた。

フェイルオーバーはプロキシのコアに任せる。今は30秒ごとに能動的な死活確認を行い、1回のタイムアウトは3秒だ。自前の回線が使えなければ、その後の接続を予備へ回し、復旧したら自前を再び優先する。すでに確立したストリーミング接続を別のサーバーへ移して続けることはできないので、切り替えにはアプリ側の再試行が必要だ。この層が解くのは、次の接続で仕事を続けられるかという問題である。

今回はHTTPSの死活確認も468回行った。自前の回線は465回、商用回線Aは459回成功し、少なくとも一方が成功した回数は468/468だった。この標本では、2回線の障害は確かに補完し合っていた。

両回線の障害が互いに独立すると仮定し、今回の失敗率から組み合わせた可用性を推定すると、約99.9877%になる。

**この仮定での概算では、組み合わせた可用性は4N水準に達する。**

短期標本と障害の独立性の仮定に基づく概算であり、共通のネットワーク障害、障害検出と切り替えの空白時間はまだ含めていない。年間の実測可用性を示すものでもない。

検証も実際の仕事に近づける必要がある。Webページを開けることや、あるAPIが成功を返すことは、モデルが長時間生成し続けるときの安定性を保証しない。自前回線と予備回線で実際のモデル出力をそれぞれ確認し、2分近い連続ストリーミングはいずれも通った。隔離環境で自前回線の障害と復旧を模擬し、予備への切り替えと復旧後の優先順位も確認した。稼働中のサーバーは止めずにテストした。

自前ノードを固定のサブスクリプション配信にも組み込んだ。接続パラメータはCloudflare経由で配布し、実際のプロキシ通信は自前サーバーへつなぐ。Macは接続済みで、スマートフォンとApple TV用の形式も用意したが、端末側の取り込みと更新は個別に検証が必要だ。今後、ノードのパラメータが変わっても、各端末へ設定を配り直さずに済む。設定のダウンロード自体は商用の予備回線を使い、自前ノードが壊れた際に更新情報まで取れなくなることを避ける。

その後、2台のMac間の協調管理も追加した。暗号化した状態同期で管理記録を共有し、同時に管理操作を実行できるのは1台だけにした。サブスクリプションを同時に変更したり、要求を重複送信したりしないためだ。

自前ノードを作ったあと、休日に解放し、平日に再作成して費用を抑える案も考えた。だが実装を進めると、新サーバーの信頼できる識別、作成要求がタイムアウトした後の照合、状態復元、複数端末の同期にぶつかった。後にこの定期的な解放・再作成案を取りやめ、既存インスタンスを動かし続け、回線の自動切り替えを維持することにした。

**インスタンスの稼働時間を少し節約するためにシステム全体を複雑にすることが、今、最も得な選択とは限らない。**

## 自分のメディアのワークフロー実践

もう1つの実験は「AI有图说」だ。一般向けにAIをテーマとする画像と文章のコンテンツを作り、このやり方でどこまで進めるか見てみたかった。

Multicaで複数Agentの小隊を組み、テーマ選び、原文照合、編集、画像作成、確認、人の承認、公開をつないだ。すでに正式に公開したコンテンツがあり、草稿だけの段階ではなくなった。WeChat公式アカウントへの公開には、引き続き私のスマートフォンでの確認を残し、公開後に正式な結果を照合する。

過程では多くの小さな問題が起きる。テーマが重複していないか、記事が発表文を言い換えただけになっていないか、画像と文章が合うか、プラットフォームは本当に保存したか。1つずつは大きな技術問題ではないが、1回の公開を完了するには順に処理しなければならない。

手順は通ったが、コンテンツ自体はまだ初期段階だ。テーマは少なく、選び方もまだ硬い。表示回数や「いいね」を論じる根拠はない。今後、実行記録とコンテンツの反応をつなぎ、何を書く価値があるか、どう表現すれば読んでもらえるかを振り返って、次のテーマ選びへ戻せるかを見たい。

まだ調整すべき点は多い。まず今の調整方式を保ち、この取り組み自体を円滑に進めたい。小さな実験として観察を続けるほうが、早々に結論を出すより面白いと思う。

## ローカルとクラウドの実行上の境界

これらを進めるにつれ、個人のデジタルアシスタントがどこで動くかを、より気にするようになった。この種のアプリは増え、クラウドでタスクを受け、ツールを呼び、私の代わりに実行できる。しかし完全なクラウド環境が、自分のローカルマシンと同じように実務をこなせるかは、いくつかの具体的な条件次第だ。

第一は認証情報の安全性。実際の仕事にはログイン状態、認証情報、Tokenが必要になる。クラウドへ渡した後、どこに保存され、誰が読め、どこまで権限を与えられ、取り消せるかを明確にする必要がある。ローカルの認証情報にも保護は要るが、保存場所と利用範囲を自分で直接管理できる。クラウドでも、同じくらい明確な境界をプラットフォームに求めたい。

第二は保存の信頼性。個人プロジェクトには、コード、ファイル、実行記録、長期的な状態が残る。永続的に保存できるか、実行資源が回収されても残るか、次のタスクが前回の結果から続けられるかは、アシスタントの実用性を左右する。1回の実行結果を返すことと、長くプロジェクトを維持することでは、要求が違う。

第三はネットワークアクセス。クラウドの通信出口では、特定のサイトやサービスが制限されることがある。ローカルなら既存のプロキシ設定で解ける問題も、クラウドで同じ対象にアクセスし、同じログイン状態を保てるかは、1つずつ検証しなければならない。インターネットにつながることは、タスクに必要な全資源へアクセスできることと同義ではない。

最後は開発とテストの環境。たとえばiOSアプリでは、現在使っているクラウド実行環境はLinuxなので、XcodeやiOSシミュレータを直接動かせない。コードを書けても、対応するツールチェーンやシミュレータがなければ、できる検証は制限される。そうしたテストには、依然としてMacか、同等のmacOSツールチェーンを提供する環境が必要だ。

**個人のデジタルアシスタントが実務でどこまで進めるかは、認証情報、保存、ネットワーク、ツールチェーンが、その仕事を継続して支えられるかにもかかっている。**

この種のアプリには、引き続きこれらの能力を補ってほしい。ファイルが残り、権限を制御でき、目的の資源に届き、書いたプログラムを実際に動かしてテストできて初めて、長期プロジェクトを任せられる。

今、サブスクリプション管理ツールはクラウドに置き、スマートフォンでもパソコンでも開けば使える。ローカルの認証情報、ネットワーク設定、Macのツールチェーンに依存する仕事は、引き続き手元で行っている。