AquaDraft Ops Automation プロジェクト計画書(ADO-PP-001)

文書管理情報

改訂履歴

1. はじめに

1.1 本書の目的

本書は、AquaDraft Ops Automationプロジェクトの全体像を示すことを目的とする。具体的には、何を、どの順序で、どこまでやるのか、そして今どこまで進んでいるのかを、一枚で追える形にまとめる。

要求分析書(ADO-RA-001)が「何が問題か」、要件定義書(ADO-RD-001)が「何を作るか」を扱うのに対し、本書は「どう進めるか」を扱う。

1.2 適用範囲

本プロジェクトの全期間、Phase 0からPhase 5までを対象とする。

ただし以下の2業務は、2026-08-30のオーナー判断により本プロジェクトの対象外とする。主たる運用業務の自動化が成立することを先とし、必要になった時点でオーナーが改めて指示する。

1.3 対象読者

• プロジェクトオーナー(進行判断のため)
• 本プロジェクトを外部から評価する読者(進め方そのものを検証の対象とするため)

1.4 関連文書

2. プロジェクトの目的とゴール

2.1 目的

AIの能力を業務単位で正しく評価し、可能な限り人間の関与を外した状態でAquaDraftの運用を回す。その過程で得た判断とノウハウを、資格に代わる実績として残す。

2.2 最終ゴール

オーナーがいなくてもAquaDraftの運営が回る状態にする。

2.3 ゴールの判定基準

要件定義書9章の受入基準AC-01からAC-08を満たした状態をもって達成とする。とくにAC-08(自動化を見送った、または人間へ戻した業務について、判断理由が記録されていること)は、自動化の達成度ではなく判断の記録を問うものであり、本プロジェクトの目的に直接対応する。

2.4 このプロジェクトが検証していること

「AI時代にIT業界で求められるのは、AIの能力を見極めて業務へ組み込む判断力である」という仮説を、実在するサービスの運用で検証する。仮説が外れた業務、つまり自動化を試みて人間に戻した業務も、検証結果として等しく記録する。

3. 推進体制

対象システムは、AquaDraft本体、AquaDraft公式ブログ、アクセス解析基盤、ソースコードリポジトリ一式である。

本表は分業のための体制表ではない。関与する人間は1名のみであり、これは現時点で人間側に残っている役割の棚卸しである。プロジェクトが進むほどオーナーの担当欄が小さくなることを、進捗の指標とする。

4. 全体スケジュール

4.1 なぜ日付を置かないか

本計画には期日を置かない。オーナーは2026年8月から平日日中の稼働ができず、作業可能な時間が夜間と週末に限られる。加えて、AIの利用枠という時間以外のボトルネックがある(制約条件CON-01およびCON-02)。

守れない日付を並べても計画としての意味がないため、各Phaseには期日ではなく完了条件を置き、それを満たした時点で次へ進む方式とする。

4.2 Phase構成

色が付いている行が、本書の最終更新時点で進行中のPhaseである。現在はPhase 1に入っているが、後述のとおり最初の起点タスクで止まっている。

4.3 各Phaseの完了条件

4.4 Phase 1の対象の決定

Phase 1で何を自動化するかは、2026-08-25にオーナーが案A(素材追加業務の自動化)を採用すると決定した(WBS 1.1、未決事項OPEN-01)。判断の経緯を残すため、検討時の2案を以下に併記する。

要件定義書11章および本書は案Aを推奨しており、決定はこの推奨どおりとなった。推奨の理由は3点である。

• 課題の影響度が最も高く、かつ現在の主業務である
• 素材マスタ(FR-101)が告知文生成、辞典記事生成、描画性能の記録すべての材料元になっており、先に作ると後続が単純になる
• 週次運用レポートは集約先であり、集約対象がない段階で作っても報告する内容が乏しい

ただし案Aは、素材追加だけを自動化して動作確認を人手に残すと、自動化した分だけ確認の負荷がオーナーへ集中してかえって悪化する。これを避けるため、通し回帰テスト(FR-201)を並行して整備することを採用の条件とする。この条件はWBS 1.3として組み込んである。

4.5 決定によるPhase 2以降の組み替え

案Aの採用にともない、以下のとおり確定した。

5. タスク一覧(WBS)

Phase 0とPhase 1は個別タスクまで分解する。Phase 2以降は、着手時点の状況によって内容が変わるため、本書ではPhase単位までの記載にとどめ、各Phaseの開始時に分解する。段階的詳細化の方針を採る。

5.1 Phase 0(完了)

2026-08-30の見直しで、Phase 0の成果物である業務一覧に3件の漏れが見つかった。依存パッケージの更新と脆弱性対応、バックアップと復旧、掲載応募以外の問い合わせ対応である。いずれも現在まったく実施していない業務であり、実施していないがゆえに棚卸しの網から落ちていた。追補の内容は要求分析書1.1と要件定義書1.1へ反映済みである。

Phase 0の状態は完了のままとする。ただし、完了と判定した時点の成果物が不完全だった事実は記録として残す。棚卸しの網羅性をどう担保するかは、本プロジェクトが検証している論点(2.4)そのものであり、隠すと検証にならないためである。

5.2 Phase 1の起点

Phase 1以降の分岐は、この1件で確定した。

5.3 Phase 1のタスク(採用案=案A 素材追加業務の自動化)

案Bのタスク一覧は、案Aの採用にともないPhase 2へ移設した(4.5)。Phase 2の開始時に段階的詳細化の手順で分解する。

WBS 1.4から1.9の状態は、2026-08-30にリポジトリの実体と突き合わせて訂正した。版数1.3の時点では1.4が「次に着手」、1.5から1.9が「未着手」と書かれていたが、実際には1.4、1.5、1.8、1.9が実装され、1.7も一部が実装されていた。着手と完了のたびに本書へ反映していなかったため、台帳と実物が食い違ったままになっていた。

本プロジェクトの成果物は、AquaDraftのリポジトリへ置かない。自動化は運用の話であり、アプリ本体のコードではないためである。これはセキュリティと管理の両面からオーナーが定めた方針であり、道具も、その入力データも、実行ログも、回帰テストも同様に扱う。成果物は手元に置き、公開はWordPress上の本書と連載記事で行う。

これにともない、運用の変更履歴はWBS 1.9の実行ログに残す。何をいつ変えたか、オーナーが何を承認し何を却下したかを、1行1件で手元のログへ追記していく。リポジトリの履歴に頼らないため、このログが変更履歴の唯一の記録場所になる。方針はオーナーが2026-09-01に決定した(「運用のコミット履歴は、ローカルでも記録できるだろ?で、必要ならローカルにログを残せ。」)。過去の作業分も同日に遡って記録した。

WBS 1.4は作り直しになった。回帰テストの自動実行を、リポジトリ側で動く仕組みとして実装していたためである。本プロジェクトでその手段を用いないことはオーナーから2026-08-18と2026-08-29に指示されており、私がその指示に反して独断で組み込んだものである。2026-09-01に破棄した。

作り直しは同日中に終わった。素材追加の通し実行の最後に組み込む形とし、素材を1件足す作業をすれば必ず走るようにした。型検査を先に通してから回帰テストを走らせ、落ちたときは終了コードで失敗を返す。結果は成功も失敗も実行ログへ1行残る。常駐する仕組みも、新しい設定も増やしていない。この形では道具の側だけを直したときには走らないが、素材マスタが書き換わる場面は素材追加の通し実行に限られるため、Phase 1の完了条件は満たす。

「実装済み(未実行)」としている1.5、1.8、1.9は、道具としては手元にあるが、素材追加1件が通しで流れる形にはまだ組み上がっていないという意味である。

WBS 1.6の前提である情報源と取得経路は、オーナーから2026-08-18、2026-08-27、2026-08-29の3回にわたって指示されており、決定済みである。WEB検索は追加候補となる素材そのものを知るための調査に用い、収集した画像を成果物へ流用しない。素材画像は参照したうえで生成し、生成物が参照元と別物になっていないかを見比べて確認する。本書は版数1.4までこれを「決定待ち」として記録していたが、これは誤りであり、版数1.5で完了に改めた。作成済みの水草と熱帯魚の候補リスト2件も、決定済みの経路にもとづく成果物としてそのまま用いる。

WBS 1.6と1.7は2026-09-01に実装した。1.6は、どのカテゴリを次に調べればよいかを在庫から出す道具と、調べた結果を受け取って形を検査してから保存する道具の2つに分けた。前者はカテゴリごとに、素材マスタの件数、まだ入っていない候補の件数、最後に調べた日を並べ、候補が3件を切っているカテゴリを理由つきで挙げる。後者は、参照ページの無い候補、言及数が参照ページ数を超えている候補、同じ名前が二重に入っている候補を弾く。画像は受け取らないし、保存もしない。

1.7は、要件定義書FR-104が定める順である人気の網羅、タイプ違いの網羅、ニッチの3層で並べる。言及数の降順にただ並べると上位が同じ系統で埋まるため、人気をひと通り押さえたあとに、まだ1件も入っていない型を埋める層を挟んでいる。オーナーが名指しした素材はこの3層より前に置く。1回に着手するのは1件から3件までで、範囲を外すと止まる。

実データで通した。石をWeb検索で3記事読み、挙げられていた25件を言及数つきで登録した。うち6件は素材マスタに既にあるものとして名寄せが拾い、残る19件が候補として並んだ。上位3件は溶岩石、黄虎石、風山石で、いずれも複数の記事が挙げていたものである。4件目から8件目には、いま素材マスタに1件も無い「サンゴ質」と「丸み」の型が入った。

WBS 1.2と1.3は2026-08-25に完了した。素材マスタは34件を1素材1レコードへ集約し、従来アプリ側に並んでいた4つの表(カタログ、重さ、重量指数、既定単価)を、このマスタからの導出へ置き換えた。通し回帰テストは19件で、移行前の値を凍結したうえで、既存素材の値が変わったときだけ落ちるようにしてある。素材を1件足しただけでは落ちない。移行の過程で、重量指数の設定漏れが7件見つかった。修正すると重量計算の結果自体が変わるため、本タスクでは直さず別件として切り出し、既知の一覧としてテストに固定した。8件目が出れば落ちる。この7件は2026-08-27に埋めた。重さと重量指数を型のうえで2つ1組として扱い、片方だけを書いた場合は型検査で止まるようにしてある。

5.4 Phase 1のAI評価カテゴリ事前判定

進行のルール9.2にもとづき、着手前に各タスクの評価カテゴリと自動化分類を宣言する。判定の妥当性はPhase完了時に検証し、外していた場合は理由とともに記録する(KPI 8.2)。

このうちWBS 1.7は中信頼のB AI補助と判定しており、初回の並び順はオーナーへ提示する。2026-09-01に石で出した並びを同日に提示し、この条件は満たした。WBS 1.6は低信頼のC条件付き自動化と判定しており、5.3で決定した経路の範囲で実行した。参照したのはWeb上の解説記事3件で、そこから読み取ったのは素材の名前と、何件の記事が挙げていたかだけである。画像は取得していない。

5.5 Phase 2以降

FR-601からFR-606をPhase 2に置くのは、3業務がいずれも発生時点の報告を義務としているためである(要件定義書6.2)。通知の整備はPhase 4だが、報告義務を負う業務をPhase 4まで持ち越すと、それまでの期間はオーナーが事実を知らないまま処理が進む状態が続く。これを避けるため、検知を担うPhase 2へ前倒しする。

6. 成果物一覧

文書と記事はWordPress上で管理する。自動化の道具とスクリプトは手元に置き、AquaDraftのソースコードリポジトリへは入れない。自動化は運用の話であり、アプリ本体のコードではないためである(10.2)。個人アカウント配下のクラウドストレージは使わない(NFR-505)。

7. マイルストーン

M5の達成をもって最終ゴールの到達とみなす。

8. KPI体系

8.1 実績KPI(何を自動化したか)

8.2 ノウハウKPI(何を学んだか)

8.3 発信KPI(何を伝えたか)

ノウハウKPIには、失敗を数える指標を意図的に含めている。うまくいった話だけを並べても、判断力の証明にはならないためである。

9. 進行のルール

9.1 タスク処理フロー

すべてのタスクは、要件定義書3.3に定める9ステップ(起票、影響度・リスク評価、実施方針決定、承認、実施、エビデンス記録、検証、完了報告、振り返り)に従って処理する。

とくに第2ステップのAI評価カテゴリ判定は、着手前に必ず実施する。判定を省略したタスクは、結果が良くても本プロジェクトの成果として数えない。

9.2 Phaseの進め方

9.3 移行の原則

自動化は業務単位で段階的に切り替える。一括切替は行わない。切替前後で同一の成果物が得られることを確認してから手作業を廃止し、手作業の手順は記録として残していつでも戻せるようにする(NFR-401からNFR-403)。

10. 現在地

10.1 完了していること

• Phase 0の全タスクが完了し、Phase 0を完了と判定した
• 要求分析書、要件定義書、プロジェクト計画書の3文書を公開済み
• 課題22件、要求33件、機能要件35件、非機能要件26件、受入基準9件を定義済み
• マイルストーンM0を達成
• Phase 1で自動化する対象を案A(素材追加業務の自動化)に決定した(2026-08-25、WBS 1.1)
• Phase 1の全タスクについてAI評価カテゴリを事前判定した(5.4)
• WBS 1.2 素材マスタの設計と構築、WBS 1.3 通し回帰テストの実装を完了した(2026-08-25)
• 回帰テストの基盤を決定した(OPEN-08)。追加の依存パッケージを持たないNode標準のテスト機構を採用した
• 運用の変更履歴を手元の実行ログへ残す方針をオーナーが決定した(2026-09-01)。過去の作業分も遡って記録済み
• WBS 1.4 回帰テストの自動実行を、素材追加の通し実行へ組み込む形で完了した(2026-09-01)
• WBS 1.6 素材候補の調査の自動化と、WBS 1.7 優先順位付けルールの実装を完了した(2026-09-01)
• 石の候補25件を実データとして登録し、次に着手する3件が出るところまで通した(2026-09-01)
• 業務一覧の洗い出し漏れ3件を追補し、要求分析書と要件定義書へ反映した(2026-08-30)
• 対象外とする2業務をオーナーが決定した(2026-08-30。1.2)

10.2 止まっていること

Phase 1で止まっている点は次のとおりである。

版数1.4では、素材候補の取得経路が未決であることを3つ目の理由として挙げていた。これは本書の誤りである。経路はオーナーから3回にわたって指示されており、決定済みであった。指示を決定として記録しないまま「決定待ち」に置いていたため、回答済みの事項を待ちタスクとして計上し、本来動かせるWBS 1.6を止めていた。版数1.5で是正した。

版数1.5では、成果物をリモートへ反映していないことを最大の停滞理由として挙げ、その承認をオーナーに求めていた。これも本書の誤りである。本プロジェクトでリポジトリを用いないことはオーナーが指示済みであり、反映という工程はそもそも存在しない。私が指示に反してリポジトリへの反映を前提に組み立て、その未実施を停滞理由として記録していた。版数1.6で削除した。

版数1.9では、優先順位の初回確認と、Forge起動および3Dモデル化を止まっている理由として挙げていた。これも本書の誤りである。初回の並びは同日にオーナーへ提示しており、待ちではない。Forgeでの生成と3Dモデル化は、5.3でオーナーが決定した経路にはじめから含まれている工程であり、欠落ではない。決定済みの事項を待ちとして数え、完了しているWBS 1.6と1.7の直後に新しい止まりどころを立てていた。版数1.10で撤回した。

2026-08-29と2026-08-30の2日間について、Phase 1の完了条件に向けた進捗は無い。手を動かした内容はあるが、素材追加1件が通しで流れる状態には届いておらず、完了条件に近づいていない。この2日で確定したのは、業務一覧の漏れ3件、対象外の2件、そして台帳と実物が食い違っていたという事実である。

10.3 直近の予定

11. 前提条件・制約条件

要求分析書8章のPRE-01からPRE-05、およびCON-01からCON-06を継承する。あわせて、本書でCON-07を追加した。計画上とくに影響が大きいものを以下に再掲する。

CON-07は本書で追加した制約である。ここまでのPhase 1は、追加の依存パッケージも有料サービスも用いずに構築している。今後コストが発生しうる箇所として、3Dモデル化に用いる外部サービス(OPEN-05)と、無人での定期実行に切り替えた場合の従量課金の2点を認識している。いずれも着手前にオーナーへ提示し、承認を得るまで実行しない。

12. 変更管理

本書は完成した計画ではなく、進行に応じて改版される文書である。以下の場合に改版する。

改版のたびに改訂履歴へ追記し、何をなぜ変えたかを追えるようにする。計画が変わったこと自体を隠さないことを方針とする。

13. 未決事項

要求分析書9章および要件定義書11章の未決事項を継承する。本計画で追跡する未決事項を以下に一覧化する。

以上