転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。
公開にあたって、自分のドメインのトップページを新しいアプリへ転送する作業がありました。
サーバーの設定ファイルに1行足すだけです。
その1行のために、AIに手順書を書いてもらいました。
手順書には「実物を読んで書いた」と明記されていました。
罠を16件洗い出し、コードを開いて確認し、机上の計画には無かった罠も2件見つけてありました。
手順書は念入りに見えました。
着手前に、手順書を書いたAIとは別の、作業側で使っているAIが外からサーバーの状態を測るコマンドを打ちました。
20本、かかったのは数秒です。
手順書と、7件ズレていました。
数秒で出た7件
| 手順書の記載 | 実物 | |
|---|---|---|
| 1 | 同じ場所に同居しているのは自作ツール2つ | 10パス以上（クライアント案件を含む） |
| 2 | 触ってはいけないDNSレコードは11本 | 37本 |
| 3 | 認証の記載なし | 4箇所に認証がかかっていた |
| 4 | 完了条件「このパスが200を返すこと」 | 403が正常だった |
| 5 | 「転送の設定を持っていることがある」（一般論） | 転送の設定が実在して動いていた |
| 6 | SSLの記載なし | 全ドメインでHTTPからHTTPSへの転送が効いていた |
| 7 | 同居はドメイン直下だけ | サブドメインにクライアントのテストサイトがあった |
手順書が嘘を書いたわけではありません。
参照した棚卸しの文書が古く、書かれた時点では正しかったものが、3ヶ月半のあいだに実物のほうが動いていました。
一番効いたのは1番です。
変更対象のディレクトリに何が同居しているかを、自分も把握し切れていませんでした。
そこには、ポートフォリオに掲載している実案件のURLも含まれています。
設定を1行書き間違えると、クライアント案件と就活の資産が同時に落ちる構造でした。
測るコストと、外したときの損失が釣り合っていませんでした。
数秒を惜しんだ先にあったのは、それです。
「照合済み」の照合先は、コードだった
なぜズレたのか。
AIが照合したのはリポジトリのコードで、これから変更を加える対象であるサーバーは見ていませんでした。
変更するのはサーバーの設定ファイルで、確認したのはアプリのコード。
同じ「実物」という言葉で、違うものを指していました。
「実物と照合済み」と書いてあっても、何を実物と呼んでいるのかを聞いていませんでした。
判定基準を「200」から「変更前と同じ値」に変えた
7件のうち4番は、検証の書き方そのものを変えることになりました。
最初の手順書の検証はこうでした。
/tool-a/ が 200 であること
/assets/ が 200 であること成功は200。
入門で最初に覚えるので、自分も疑わずに読んでいました。
実際に測ったら、4箇所で誤判定する書き方でした。
| パス | 実測 | 200を期待すると |
|---|---|---|
/assets/ |
403（一覧表示の禁止） | 正常なのに「壊れた」と読む |
| 認証つきの3箇所 | 401（認証待ち） | 同上 |
直し方は、AIから2つ提示されました。
- A: 個別に覚える。「ここは403が正常」「ここは401が正常」と手順書に書く
- B: 判定基準を変える。「変更前と同じ値が返ること」にする
AIはBを勧め、自分もそれで進めることにしました。
覚えるべきことが全部消えます。
認証が1つ増えても手順書は嘘になりません。
棚卸しが古くなっても壊れません。
増えるのは「変更前に測る」という一手間だけで、それは数秒です。
Aを選んでいたら、手順書に例外リストが育ち続けていたと思います。
覚え漏れた分だけ穴になる方式です。
Bは「何が正常か」を知らなくてよくなる書き方でした。
ただし、変更前の値が取れる作業でしか使えません。
新規構築には使えないので、一般化しすぎないようにしています。
「戻せる？」と聞いたら、手順書に無い前提が3つ出た
7件を反映して、いよいよ1行足す直前になりました。
そこで、自分から聞きました。
「元のページの内容は保存されている？ 復元しようと思えばできる？
いつかこの作品を削除することになった時に、今の構成に戻せる？」
答えは「できます」で合っていました。
でもAIが推測で答えずに実測したので、手順書に書いていない前提が3つ出てきました。
1. その設定ファイルは、サーバー上にしか無かった
| 場所 | ある？ |
|---|---|
| 本番サーバー | ここだけ |
| 手元 | 無い |
| GitHub | 無い（バージョン管理の外） |
サイト本体は3重に残っています。
でも、この設定ファイルだけは世界に1つしかありませんでした。
壊したら復元元が無い。
「触る前に控えを取る」は最初から手順書に書いてありました。
でも「控えが唯一の保険になる」ことは書いていませんでした。
重みがまるで違います。
2. 中身は2種類だと思っていたが、3種類目があった
外から観察して、2種類の設定が入っていると推定されていました。
3種類目は、別のリポジトリの README に書いてありました。
「この設定ファイルで、リポジトリの管理フォルダへのアクセスは404にしている」
セキュリティ設定でした。
知らずに書き換えていたら、リポジトリの中身が外から見える状態に戻していました。
3つの中でいちばん実害が大きいのがこれです。
そして書いたのは、過去の自分でした。
3. 転送を入れても、直接ファイル名を叩くと元のページが見える
指定した書き方はトップだけにマッチします。
だから /index.html を直接叩くと、元のページがそのまま見え続けます。
元ページの確認に使える利点でもあり、検索エンジンには重複ページに見える欠点でもあります。
検証項目を決める前に知っておきたいことでした。
3つとも「開いた後では遅い」前提だった
- 1は、控えを取る前に知っておくこと
- 2は、書き換える前に知っておくこと
- 3は、検証項目を決める前に知っておくこと
そして3つとも、この作業の手順書には書いていませんでした。
出どころは、別のプロジェクトの README でした。
触る対象が別プロジェクトの成果物なら、そのプロジェクトのドキュメントが一次情報です。
この作業の手順書をいくら読み返しても出てきません。
聞いたのは「戻せるか」で、出てきたのは「壊す側の前提」でした。
質問に答えてもらうために調べたら、質問と関係ないものが出た形です。
手順書があったから止まれた
結論は「AIの手順書は当てにならない」ではありません。
手順書があったから、着手前に測るという段取りが取れました。
罠を「断定していない」書き方にしてあったので、実物と違っても詰まらずに済んだ場面もあります。
文書は古くなります。
古くなることを前提に、着手時に測る。
数秒で済むものは、惜しまない。
そして「照合済み」と書いてあったら、何と照合したかを自分が聞く。
その一言で、7件のうちいくつかは手順書の段階で出ていたと思います。
