> 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/w38-everything-can-be-engineered.md).

# W38-あらゆるものをエンジニアリングできる

最近取り組んだいくつかのことを通じ、AI が複雑な問題への向き合い方を変えていると、ますます強く感じる。

以前は、問題がある程度複雑になると、注意をさらに注ぐしかないことが多かった。設定を覚え、文書を保ち、背景を繰り返し説明し、間違えたら調べる。プログラムで解決できると分かっていても、そのために仕組みを作り、保守する価値があるとは限らなかった。

今は、それを一つの開発プロジェクトにしたいと思うようになった。

事実とルールを書き、反復作業をプログラムに任せ、変更に検証を加え、履歴と戻す経路を残す。新しい要件が来れば、その土台の上で拡張する。

エンジニアリングの方法は、以前から存在した。**AI が実装と保守の費用を下げたことで、以前は割に合わなかった多くの仕組みを、作る価値が生まれた。**

## プロキシ設定を保守できるプロジェクトへ

最初の例は、私の Mac のプロキシ設定だ。

当初は、いくつかのアプリが正常にネットへ接続できればよかった。要件が増えるにつれ、サイト別の経路振り分け、社内ネットワークへの直接接続、コマンドラインとデスクトップアプリの環境差、設定更新、端末移行まで関わるようになった。

一つずつ扱えば難しくない。しかしルールが重なると、記憶だけで維持するのは難しい。今日問題を解決しても、しばらくすると、なぜそう設定したか忘れ、次の変更がどこへ影響するかも分からなくなる。

そこで、この仕組みをプライベートリポジトリへ整理した。

設定テンプレート、振り分けルール、生成と検証のスクリプトに加え、復旧、保守、トラブルシューティングの手順書を置いた。変更前にプレビューでき、導入前にバックアップでき、問題があれば戻せる。別の Mac への移行にも、明確な手順と受け入れ条件がある。

実際に別のパソコンへ移行し、有効性と効率を確かめた。以前は一つずつ調べて手で設定していた作業を、リポジトリのルールと手順に沿って行える。このプロジェクトは、実測で確かめた再利用性を得た。

私にとっての変化は、この設定をようやく長期保守するシステムとして扱えるようになったことだ。アプリを追加し、ルールを調整するとき、直す場所と検証方法があり、過去に何をしたかも追える。

**複雑さは残るが、置き場所と扱い方が明確になった。**

## Agent Team 自体にもエンジニアリングが必要だ

二つ目は、しばらく運用している Agent Team だ。

一人で仕事をし、Agent が一つか二つなら、直接会話してタスクを割り当てれば、通常は十分だ。

しかし複数の Agent に役割別の仕事を任せ、自ら組織し、協働して複雑な問題を解かせるには、明確な運用ルールが必要になる。

誰がタスクを分解し、誰が実装し、誰がレビューするか。どう引き継ぎ、問題が起きたら誰が引き受けるか。事前に決める必要がある。チームやプロジェクトに自動化タスクを追加すれば、その起動と実行も管理する。例えばコード変更を自動で探して PR review を行う、統合リポジトリへのマージ後に対応する内容を各サブリポジトリへ自動で反映する、といった作業だ。

これらは、数本のプロンプトを手で保つ範囲を次第に超えた。そこで Agent の役割設定、協働ルール、自動化タスクを、管理、運用、継続的な拡張ができるプロジェクトにまとめた。

役割の責務、協働ルール、実行方針をリポジトリに保存する。リポジトリがチームのあるべき状態を宣言し、同期ツールが実際の稼働状態との差を調べる。変更は先にプレビューし、適用後に一致を確認できる。

そのため、毎回組み直さずにチームを調整し続けられる。

**一度うまくいった協働の経験を、関係するすべての役割が守るルールにできる。**

失敗で明らかになった問題も、設定や検証手順に組み込み、次の仕事の土台にできる。

私は Agent Team を、運用と改善が必要なシステムとして扱い始めた。モデルの能力はその一部であり、役割の境界、引き継ぎ、受け入れの方法も、継続して改善する必要がある。

## チームの作業文脈を同じバージョンに収める

三つ目は、進行中の税務申告 MVP だ。

BFO の統合リポジトリでこのプロジェクトを進めている。製品・アーキテクチャ文書、API 契約、受け入れ仕様、フロントエンドとバックエンドのコード、Agent ツールを同じ統合リポジトリへ入れ、共通のバージョン基準にする。

**文書をコードとして扱い、コードを製品につなげる働き方を実現したい。**

製品ルールが変わったとき、関連文書、契約、実装、受け入れ基準を一緒に変更し、レビューできる。あるバージョンへ戻り、その時点の要件、実装、正しくできたと判断する基準を確認できる。

以前、こうした文脈は文書、チャット履歴、それぞれの記憶へ散らばりがちだった。役割をまたぐ協働では、繰り返し運び、説明する必要があった。プロダクト担当が一度説明し、開発者が理解し、テスト担当がさらに再構成する。要件が変われば、全員が同じバージョンを持っているかも確認し直す。

統合リポジトリは、この仕事に共通の根拠を与える。

人同士の理解の違いは消せないが、資料探し、版の照合、背景の繰り返し説明の費用を減らせる。具体的な変更を軸に議論でき、結論を残す場所も明確になる。

AI も同じ資料を読める。タスクを受け取ると、要件、契約、実装、テストをたどって文脈を探せる。現在の会話で一時的に与えられた情報だけに頼らずに済む。

MVP はまだ進行中で、長期的な効果は今後の検証が必要だ。それでも、特に重視しているのは、その後の日常的な改善だ。これらの資産を製品と一緒に保守すれば、一回の仕事が、次の仕事により完全な土台を残せる。

**過去の仕事が、将来の仕事の費用を下げ続けられる。**

## 財務管理における事実と表現

四つ目はまだ実現していない。計画中の個人財務・投資管理のプロジェクトだ。

今は Google Drive で家計の週次、月次、四半期の確認資料を管理し、市場の観察も続けている。

これらを徐々にプライベートなプロジェクトへまとめたい。家計の基本状況、投資対象、投資経路、市場観察、定期的な確認記録を含める。

**最も魅力を感じるのは、事実の基盤と表現方法を分けられることだ。**

以前は情報を表、文書、PPT のどれで記録するか決める段階で、最終的な見た目を考えがちだった。データの整理方法が、表示ツールに左右されやすかった。

今後はまず、出典、時点、バージョンを持つ基礎記録を保ち、具体的な問いに応じて表現を生成したい。

資産構成を見たければ図表を作る。月次確認をしたければ報告書を作る。ある変化を知りたければ、履歴をたどって問いかける。異なる見せ方が同じ基礎データから生まれ、どれもそこへ戻って照合できる。

これなら、表現のたびに事実を整理し直さずに済む。図表や報告書はいつでも作り、調整できる。長期保守の重点は、基礎情報の正確さ、完全さ、鮮度に置く。

エンジニアリングへの理解も、ここで一段変わった。プロジェクトには事実、ルール、意思決定の記録を収め、必要に応じて人が読み使う画面を生成できる。

## AI はエンジニアリングへの投資を回収しやすくする

これらの事例には共通点がある。どれも一定の複雑さが積み上がり、継続的な保守を必要とする。

以前なら、そのために開発プロジェクトを作ろうとは思わなかったかもしれない。スクリプト、文書、検証、ツールの保守には投資が要る。個人の多くの要件は規模が小さく、便益が費用を覆えず、手作業を続けることになっていた。

AI はこの投資を小さくした。

設定の整理、スクリプトの作成、テストの追加、文書の保守が安くなると、エンジニアリングの方法で扱いたい問題が増える。プロキシ設定、Agent の協働、チームの作業文脈、さらには家計も、その範囲に入ってきた。

**信頼性には、なお具体的な仕組みが必要だ。**

事実を照合し、変更を検証し、失敗を発見でき、必要なら戻せなければならない。AI はそれらの構築と保守を助けるが、代わりにはならない。

土台があるからこそ、安心して機能を増やせる。**システムが扱える問題が増えても、私の記憶と注意を同じ割合で増やす必要はない。**

今、あらゆるものをエンジニアリングできるという判断が、ますます明確になっている。

より正確には、**問題の中に明確に記述、計算、検証できる部分があれば、それを継続的に保守できるプロジェクトへ組み立てる機会がある。**

判断と取捨選択は引き続き人が担う。その周囲の情報整理、実行、フィードバックは、改善し続けられる。

以前は複雑な問題に出会うと、まずどれだけ力を注ぐ必要があるかを考えた。今は、後からも育て続けられる仕組みを作れないかと、先に考える。