2026年11月9日（月）の開発記録です。
前日はサーバー内の不要な資材を整理し、容量不足で開発が止まる問題に対処しました。今日は開発そのものの進め方を整理しながら、AIによる開発の自律化と習慣記録アプリ「ほめつみ」の開発を進めました。
AIによる開発の自律化がひと区切り
これまでChatGPTを使ったサーバー開発では、プルリクエストの統合や本番環境への反映など、さまざまな場面で私の承認が必要でした。もちろん、重要な変更に人間の判断を挟むことには意味があります。
ただ、実際にはAIが作成したコードを私がすべて精査できるわけではありません。テスト結果や変更内容を確認して、最終的に「承認します」と返すことがほとんどでした。
それならば通常の開発については、適切な品質検証を通過した段階で自律的に統合・配備まで進め、結果を報告してもらうほうが合理的ではないか。一方、権限や認証機構の変更、取り返しのつかない操作まで自由に実行させるわけにはいきません。
この区別を実装するため、ここ数日、Development MCPとRunnerを改修していました。そして11月9日午前、予定していた4工程が完了しました。Publishing MCP、Knowledge MCP、Development MCP、Runnerの4つについて、通常変更を追加承認なしで処理する経路を確認できました。
ただし、ここに至る作業は想定よりずっと大きなものでした。当初の見積もりは2件のプルリクエストと最大8回のサービス更新でしたが、最終的には累計9件のプルリクエスト、24回のサービス更新となりました。テスト環境では見えなかった問題が実環境で発覚し、その修正と検証が繰り返されたためです。
完成はしましたが、最初の設計と検証が十分でなければ、後工程で作業が大きく膨らむことを実感しました。
「ほめつみ」の開発をいったん整理し直す
この日、もう一つ大きく進めたのが「ほめつみ」です。毎日の行動を記録して、その積み重ねを具体的に褒めてくれる習慣記録アプリとして開発しています。
アプリのコードやAndroid用APKはすでに存在していました。テストも多数通過しており、一見すると完成に近いように見えます。しかし、実際に使える状態になっているかといえば、そうではありません。
サーバーにアプリを配置し、HTTPSでアクセスし、データを保存して、Androidからも使える。そうした一連の動作が実環境で確認できていなかったのです。
開発を進めていると、目の前のエラーを修正することに意識が向き、そもそも何を完成させようとしていたのかが曖昧になってしまうことがあります。そこで、いったん仕様書に戻りました。
元の仕様を読み直し、既存の実装と比較し、完成までに必要な工程を整理しました。
- Web/APIを実環境で動作させ、基本機能を確認する。
- Androidアプリを実際に操作し、使い勝手を確認する。
- バックアップ、復元、オフライン利用、端末間同期を確認する。
- 日またぎの動作や復帰機能を検証し、最終受入を行う。
重要なのは、開発途中で勝手に完成条件を小さくしないことです。テストが成功したから完成、APKが生成できたから完成、というわけではありません。実際に日常的に使えることを完成条件として、開発を進め直すことにしました。
1万件を超えるテストと、実環境での確認
工程を整理した後、まずはWeb/APIを動作させるための基盤を進めました。
PostgreSQL 16を用いた実環境に近い検証では、行動の記録、称賛、保存、再取得などの基本操作に加え、認証や異常なデータベース状態への対応も確認しました。
34項目の検証が成功し、その後の全体品質検証では10,300件のテストが成功しました。さらに、GitHubから製品コードを取得する仕組みの修正でも10,309件のテストが成功し、関連するプルリクエストを統合できました。
もっとも、テスト数が多いこと自体が重要なのではありません。実際の環境でも動くこと、そしてテストでは確認できていない部分を把握していることが重要だと思います。
今回もコードの検証を通過した後で、サーバー上のディレクトリ権限や所有権の問題が発覚しました。これらは対象を限定して修復し、最終的にはGitHubから正しい製品コードを取得するところまで進められました。
ソフトウェアの開発は、コードを書いて終わりではないのだと改めて感じます。
GitHubの鍵と、無料で使えるHTTPS
今回、少し理解に時間がかかったのが、GitHubの認証鍵でした。サーバーが非公開のGitHubリポジトリからコードを取得するために、専用の鍵が必要だったのです。
最初はなぜここで新しい鍵を作らなければならないのか、構造がよく理解できていませんでした。そこでAIに、何のための鍵なのか、回避する方法はないのか、一般的な運用として合理的なのかを確認しました。
結果として、対象リポジトリへの読み取り専用Deploy Keyを使う方針にしました。必要なアクセスだけを許可でき、秘密鍵をサーバー外に出す必要もありません。
もう一つ、HTTPSの問題もありました。アプリをWebで利用するには、固定のURLとHTTPS接続が必要です。ところが、私はこのアプリ用の独自ドメインを持っていません。
最初は独自ドメインの用意が前提になりかけていたのですが、要件を確認すると必要なのは独自ドメインの所有ではなく、HTTPSでアクセスできることでした。
そこで、IPアドレスからホスト名を生成できる無料DNSサービス「sslip.io」を利用する方向に変更しました。11月9日の時点では、候補のホスト名がサーバーのIPアドレスに正しく解決されるところまで確認できています。
ただし、証明書の発行や実際のHTTPS接続、アプリの本番配備はまだ完了していません。ここは翌日以降の課題です。
WordPressのアイキャッチ画像を変更する機能も開発
この日はブログ運営に使用しているPublishing MCPについても、小さな機能追加を進めました。
公開済みの記事について、アイキャッチ画像だけを後から変更できる機能です。記事のタイトルや本文、公開状態などは変更せず、WordPressの featured_media だけを書き換えるというものです。
AIに記事を作成・投稿してもらう運用では、こうした小さな操作ができるかどうかで使い勝手が変わります。
今回は必要な機能だけを開発対象とし、周辺機能の改修や新たな仕組みの追加は求めないことにしました。実装済みとの報告は受けていますが、この日誌の整理時点では、関連するテストの最終証拠まで確認できていないため、ここでは開発を進めた項目として記録しておきます。
AI開発で難しいのは、完成までの道筋を維持することかもしれない
ここ数日の開発を通して、AIにコードを書いてもらうこと自体は、もはやそれほど難しくないと感じています。
難しいのは、そのコードが本来の目的に沿っているかを確認しながら、完成まで作業を進めることです。
エラーが発生すれば修正が必要になります。修正すればテストが必要になります。そこで新たな問題が見つかれば、また修正が始まります。一つひとつの判断は合理的でも、積み重なると、当初の開発計画から大きく離れてしまうことがあります。
今回の「ほめつみ」では、その状態を避けるため、仕様書と完成条件を固定し、工程ごとに照合することにしました。
また、長時間のテストが実際に進んでいるのか、それとも停止しているのかを判断することも重要な課題です。
今回はJob、ログの更新、成果物、テスト結果を使って進捗を確認しましたが、Workが切断された後も自律的に5分ごとに確認し、必要なら再開する仕組みが完成したわけではありません。この問題もまだ残っています。
AIの自律性を高めたい一方で、何を任せ、何を確認すべきなのか。その線引きは、開発を重ねるほど重要になっている気がします。
今日のまとめ
11月9日は、AIによる通常開発の自律承認モデルが完成し、「ほめつみ」の開発も仕様に立ち返って整理し直した一日でした。
自律承認モデルについては、既存の4サービスで実際の動作確認まで完了しました。一方、「ほめつみ」は実装やテストが大きく進んだものの、実際に使える状態にはまだ至っていません。
次はHTTPS接続とアプリの配備を完了し、実際の画面で動作を確認する段階です。
サーバーの容量問題を整理した前日に続き、今日は開発工程そのものを整理できました。
AIを使った開発では、何でも自動化すればよいというものではなく、何を完成とするかを明確にし、その条件を最後まで維持することが大切なのだろうと思います。
開発はまだ続きます。
コメント