ソフトウェア設計 on 或る阿呆の記

バイブコーディングでジェンガが崩壊したらどうするのか？

Wed, 16 Sep 2026 00:00:00 +0900

現在自分用のアプリケーションとして、体重計やFitbitのようなトラッカーのデータを集約し、さらに手動で体調不良などのイベントを管理したり、運動管理したり、データに基づいてAIに分析させるようなアプリケーションをAIで作成しています。

その過程で、内部的な設計を変更したのですが、今後こういう判断を誰がしていくんだろう、あるいは誰がどうやって必要だと学ぶんだろう、とふと思いました。

設計の変更

まぁ最初は今あるデータをホイホイ読ませて、それ十分だったのですけれど、読み取るデータが多岐に渡ってくるにしたがって、内部の設計について気になり始めました。恐らく、データソースと取り込みが密結合になっているだろうなぁ、と思ったので。聞いてみるとやはりそうだったのですが、何を言っているかと言うと、図示すると以下のようにデータソースと取り込みロジックが1vs1で完全に対応してしまっている状態です。

flowchart TD
subgraph External["外部データソース"]
GH["Google Health API (JSON)"]
TO["Google Takeout (ZIP / CSV)"]
EU["Eufy 体重計 (BLE / CSV)"]
end
subgraph TightlyCoupled["各機能内部（変換と永続化が一体化）"]
GH_All["Google Health クライアント\n・JSONパース\n・独自集計ロジック\n・個別 INSERT / ON CONFLICT SQL"]
TO_All["Takeout インポーター\n・ZIP / CSVパース\n・独自集計ロジック\n・個別 INSERT / ON CONFLICT SQL"]
EU_All["Eufy 処理（新規追加時）\n・データパース\n・個別 INSERT / ON CONFLICT SQL"]
end
DB[("SQLite データベース\n(daily_metrics / body_measurements)")]
GH --> GH_All
TO --> TO_All
EU --> EU_All
GH_All -->|"直接 SQL 実行\n（マージルールが分散）"| DB
TO_All -->|"直接 SQL 実行\n（マージルールが分散）"| DB
EU_All -->|"直接 SQL 実行\n（マージルールが分散）"| DB
classDef issue fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#b71c1c;
class GH_All,TO_All,EU_All issue;

コレの何が良くないかと言うと、同じデータでもGoogle Health API経由なのかそれともエクスポートcsvデータなのかで完全に異なるロジックになってしまうわけです。これは拡張性と保守性の両方に問題があります。

なので、設計をデータソースと取り込みの間に、フォーマットするレイヤを増やして疎にしました。

flowchart TD
subgraph External["外部データソース"]
GH["Google Health API (JSON)"]
TO["Google Takeout (ZIP / CSV)"]
EU["Eufy 体重計 (BLE / CSV)"]
UI["画面からの手動入力 (Web UI)"]
end
subgraph Converters["データ変換レイヤ（副作用のない純粋関数）"]
GH_Conv["Google Health コンバータ\n（JSON ➔ 共通モデル）"]
TO_Conv["Takeout コンバータ\n（ZIP ➔ 共通モデル）"]
EU_Conv["Eufy コンバータ\n（BLE / CSV ➔ 共通モデル）"]
end
subgraph CoreDomain["アプリケーション共通仕様"]
Models["共通ドメインモデル\n・models.DailyMetric\n・models.BodyMeasurement\n・models.ActivityLog"]
end
subgraph Ingestion["データ取り込みレイヤ (internal/ingest)"]
IngestSvc["統一 Ingest サービス\n・トランザクション制御\n・安全なマージ制御 (COALESCE/部分更新)\n・source メタデータ自動付与"]
end
DB[("SQLite データベース\n(source カラム付き)")]
%% データフロー
GH --> GH_Conv
TO --> TO_Conv
EU --> EU_Conv
GH_Conv --> Models
TO_Conv --> Models
EU_Conv --> Models
UI --> Models
Models --> IngestSvc
IngestSvc -->|"一元化された SQL で永続化"| DB
classDef pure fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1b5e20;
classDef service fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#0d47a1;
class GH_Conv,TO_Conv,EU_Conv pure;
class IngestSvc service;

これでまぁ、今後対応すべきデータソースが増えてもやりやすくなったはずです。とりあえずコードはだいぶリファクタされました。

そしてジェンガが出来る

思ったのは、今後主流になるだろうAIによる開発において、設計変更を伴うような判断を誰ができるのだろうか、ということです。今回の場合、継続的にインタフェースが増えそうだなぁ、と判断した時点で中間層をいれるようにしましたが、自分で言わないと、多分AIは前例踏襲で密な結合を増やし続けたと思います。

それは拡張を続けていくと破綻しそうです。それともAIならば頑張れるんだろうか？あるいは、AIが頑張れなくなるまで拡張を続けてしまうのだろうか。まぁそこまで使い続けられたらそのアプリはある意味成功なのかもしれませんが、であればこそ使い続けられるような状態にしたいところでもあります。

もちろん、最初から完全な要件を提示すれば、相応しい設計を最初からするに違いありませんが、それができるなら誰も苦労しません。アプリケーションはしばしば、自分も何が欲しいのかわからないところから始まります。特にAI時代、まず形にして、自分自身がまず何をしようとしていたのかを知るほうが、効率も良いでしょう。

しかしそれだと、恐らくジェンガが出来ます。そのジェンガは最終的にAIと自分の能力を超えるところまで積み上げられます。

ジェンガ上等かもしれない

まぁでも、いいのかもしれません。崩壊する前に仕様が完全に固まって固定されれば、それは賭けに勝った、という感じですし、たとえ目に見えて破綻しても、そのときには欲しかったものがかなり目に見えているはずですから、そこから仕様を改めて洗い出し、言語化して、AIに最初から作らせる、データは頑張って移行する、というのでも十分ペイするのかも。

もちろんそうなる前に設計変更すりゃいいんですけれど、これからはそれが出来る人自体が減っていくように思われます。だいたいそれを学ぶ場がなくなっていくのは、これはもう確定的なシナリオですし。であるならば、むしろやるべきことは、最初から作り直せる状態に留めること、なのかもしれません。つまり規模であったり、データ形式であったり、アカウントの範囲であったり、影響範囲であったり、そういったやり直すために必要な勘所を抑えて、スクラップビルドが現実的な範囲でアプリケーションを有効に活用していく、そういう対応が有効なのかなぁと、そんなことを思いました。

と言いつつ、僕はそんなめんどくさいことは嫌なので、自分の作るものについては、継ぎ接ぎが破綻しないよう考えながらやります。実際、一からはすごいしんどいと思いますよ。壊す必要がなければそれが一番ですからね。一応ニューゲームも現実的に対抗可能な範囲であるとして、最終手段の保険といったところでしょうか。

AIプログラミング開発日誌7: 外部プラグインの機能でかなり苦戦

Sun, 17 May 2026 00:00:00 +0900

ずっとAIプログラミングやっている。自分用のものがほとんどだが、いくつかは公開してもいいかもしれない、と思うものも出てきた。これは書籍管理をしているところ。

人に見せても問題なさそうなラインナップ

ざっと見てなんとなく見栄えはするかなぁと思うのだけれど、これくらいのものでも、さすがに非エンジニアにはだいぶ敷居が高いままだ…と思う今日この頃。まぁもちろんそれは用途次第であって、コンバータとかちょっとしたものならいいと思うんだけれど。今僕が時間をかけて作っているデジタルコンテンツの管理アプリDigitalShelf（仮）（v0.20.0までいったがv1はとおい）は激しいDB設計の変更などがあり、非エンジニアだと間違いなく破綻するだろうということが何度もあった。

AIにはしんどい機能だった

特に今回の変更はしんどかった。今後配布することを念頭に、ユーザがアプリケーションの機能を拡張できるようなプラグイン機能を作っていたのだが、今までで一番引っかかったかもしれない。

もともとは、ffmpegなどの外部コマンドに依存する特殊な機能をどうインストールするか、というのが問題だった。特にソースコードを開示する気がなくなったため、GPLの扱いは慎重にならざるを得ない。ソースコードを開示しないのは、なんか最近セキュリティの名目でAIによるOSSアタックという謎のプレイが流行しているからだ。ただでさえOSSなんてボランティア精神が必要なのに、なにをしているのか…。

ということで、配布するならバイナリかなぁと思ったのだが、そうするとpdftoppmやffmpegといった外部コマンドのインストールをどうするかな、という問題が立ちはだかる。特にGPLは混ぜると開示せざるを得なくなってしまうし。

それで、外部コマンドについてはプラグイン形式とすることで、ライセンスやインストールの問題をクリアしつつ、拡張性をもたせようと思った。これは実際応用範囲が広いし、ユーザが好き勝手できる良い機能だ。たとえばyt-dlpを使った機能なんかはさすがに配布しづらいわけだが、個人がプラグインとして導入する分には勝手なので、自由度が大きく広がる。whisperなんかも混ぜれば、手軽に動画のDLと文字起こしで検索システムも作れそうだ、などと考えていた。

AIに着想を伝えたところ、AIも「それはたいへん素晴らしいアイディアです」といつものことながら礼賛して、いきなり実装を始めたのだが、まぁこれがカオスであった。データベースからワークフローの設計までかなり手をいれることになってしまった。

AIに任せきりにしても一応機能自体は実現するのだが、無数の変数と設定項目の入り組んだとんでもなく複雑なカオスが出来上がるのである。なぜ設定が必要なのか不明な項目、手順を先に指定した後に目的と名前を聞くような不可解な順番、無限に増える変数……明らかに管理不可能である。

それで結局、不要な項目とデータベース設計の冗長な部分を指摘しつつ、自分で要件を決め直して、かなり根本的なところから実装させなおす必要があった。まぁなんとか形にはなってきたんだが…。

その過程で出来ていたものがまた出来なくなることも多々あり、大いに苦労した。

AIプログラミングの実際的しんどさと、恐らくの無理解の乖離

これはAIというやつの性質がよく出ている。AIは局所的プログラミングの天才なのだが、全体を見通すことに書けては鈍才もいいところなのだ。しかしシステムというやつはどんな小さなものでも全体の整合がすべて。なので、目的を見据えながら全体を見通し帳尻をあわせて整えるという、一番しんどいところが結局人間任せであるから、結局時間はかかるし苦労もする。要件定義に基づいてアーキテクチャ設計とデータベース設計という、抽象と具体の極致でそれぞれAIを制御しないといけない。

こういう感じで普通に人日がかかっているので、完全AIプログラミングで制作しました！として公開し、もしそれを「AIで作ったんだから誰でもすぐできるようなものなんでしょ」と言われるとムカッとするだろう。

多分AIでコーディングしている人たちは大なり小なりその難しさについて実感しているはずで、「確かに開発速度は上がったがエンジニアが不要になるはずがない」というのは完全にそのとおりであると思う。一方で、開発速度が上がっていることも事実であり、明らかに1人で数人の業務委託を切れるくらいのスピード感になっているはずだ。

となると、エンジニアが今までどおり必要とされるには、ソフトウェアの需要もやはり数倍になる必要がある。もしかしたら数十倍かもしれない。しかし、「ITエンジニアの不足」が言われていたのは確かだが、さすがに数倍や数十倍必要というわけではなかったはずだし、またそもそも本当にソフトウェアにそこまでの需要が本来あったのかも疑わしい。

なので、結局ITエンジニアの需要については強烈な下落圧力がかかるはずで、ソフトウェアエンジニアはもうオワコン、とは言わずとも中長期的にはやはり厳しくなるのではなかろうか。しかも周囲からはどうせAIがやってるんでしょ？という目で見られるのだろうし、そういったことは評価や給与に反映されるのだろう。現実に難しいかどうかは問題ではない。世間の人がどう思うかが問題なのだ。現実の難しさと需要で給与が決まるなら人手不足倒産なんか起きていない。どんなにしんどかったり難しかったりしても、人がそれに対価を払いたくないと思うのであれば、ただ取引不成立になるだけだ。

ITエンジニア初めての逆風？

結局、ひたすら職業として上り調子であったソフトウェアエンジニアにとって、初めての社会的な逆風ということになるかもしれない。個人的には、ソフトウェアエンジニアはむしろ他業界に散らばったほうがいいと思っているし、僕自身はもはや組織から離れたので、別にもういいのだが、しかしまぁ、今後のエンジニア業界がどうなっていくのかは、興味深く見守っていきたいところだ。

<関連記事>