AquaDraft Ops Automation 基本設計書(ADO-BD-001)

文書管理情報

改訂履歴

1. この文書の位置づけ

1.1 目的

本シリーズはここまで3本の文書を公開してきた。要求分析書で「今どうなっているか」を洗い出し、要件定義書で「何をどこまで自動化するか」を定め、プロジェクト計画書で「いつ誰が何を作るか」を並べた。

残っているのは一つである。それをClaudeのどの機能を使い、どのように設定して動かすのか。本書はそれを定める。

1.2 設計完了の条件

本プロジェクトにおける「自動化の設計が完了した」の定義は、オーナーが2026年8月30日に言葉で定めている。以下がその条件である。

• 自動化を全体フローで洗い出す
• それぞれ詰める
• 漏れ抜けをチェックする
• Claudeがやるのか、オーナーしかできないのかを、すべてのタスクで確認する
• 全体フローが決まったら、それをClaudeのどの機能を使って、どのように設定するのかを決める

この5つが揃って、自動化の設計として完了である。本書の執筆時点での達成状況は次のとおりである。

1.3 本書を書くに至った経緯

正直に記録しておく。設計が完了する前に、個別の実装へ着手していた。回帰テストの整備、候補素材の調査、優先順位付けを順に作っては「完了しました」と報告していた。さらに「最初の自動化」という、計画書のどこにも存在しない作業単位を自分で作り、それを現在地として報告していた。

オーナーからの指摘は明確だった。設計の完了条件は既に言葉で定めてあり、その最後の一項目が埋まっていない。埋まっていないものを飛ばして実装を進めれば、何を作っているのかを誰も承認できない。

もう一つ原則がある。承認は目に見える形のものに対してしか出せない、というものである。作業用に作ったマークダウンファイルは根拠にならない。決まったことは、記事か会話で示す。本書を公開文書として出すのはそのためである。

版数1.1で、もう一度同じ性質の指摘を受けた。初版は、工程の側に「スキル」「手元のスクリプト」と機能の種類しか書いておらず、どのスキルか、どのスクリプトかを名指ししていなかった。機能の側の一覧も工程を網羅していなかった。つまり、機能と工程が紐づいていなかった。「どの機能をどう設定するか」という条件は、種類を書けば満たされるものではない。名前で指して、両方向から辿れて初めて満たされる。

紐づけを詰める過程で、初版の記述が実態と食い違っている箇所も3つ見つかった。プラグインを作成済みと書いたが存在しないこと、定期タスクとして登録できているのは1件だけであること、道具の呼び出し方が実物と違うことである。いずれも版数1.1で訂正した。

1.4 関連文書

2. 設計の前提

2.1 三つの軸を分ける

「自動化する」という一語には、性質の違う三つの決めごとが混ざっている。これを分けないまま議論すると、機能名だけが飛び交って何も決まらない。本書では以下の三軸に分けて設計する。

同じ「素材の候補を調べる」でも、週に一度勝手に走るのか、オーナーが呼んだときだけ走るのかで設計は変わる。実行の場を先に決め、そこへ中身を載せる順序で設計する。

2.2 実行の場の候補

実行の場になり得るものを、追加費用の少ない順に並べる。

2.3 背骨は定期タスク

自動化の背骨を、手元の環境で動く定期タスクに置く。ルーティン(クラウドで動く定期実行)ではない。根拠は二つある。

一つ目は、クラウドからAquaDraftのリポジトリへアクセスする権限の要求が拒否されたことである。非公開リポジトリのため、クラウド側の実行環境がコードを取得できない。

二つ目は、クラウドからは手元の認証情報ファイルが読めないことである。ブログの投稿にもWordPressへの接続にも認証が要る。その値は手元にしか置いていないし、置き場所を変えるつもりもない。

したがって、週に一度勝手に走る仕組みは手元の定期タスクで作る。この判断は2026年8月30日に確定した。

2.4 無人化という言葉の二つの意味

本プロジェクトの最終ゴールは、オーナーがいなくてもAquaDraftの運営が回ることである。ここで「無人」には二つの意味があり、必要なのは後者である。

• パソコンが起動していなくても動くこと
• オーナーが手を動かさなくても動くこと

前者を満たすにはクラウドが要るが、2.3の理由で今は成立しない。後者は手元の定期タスクで満たせる。パソコンが起動していれば、オーナーが何もしなくても処理は進む。本設計は後者を目標に置く。

2.5 リポジトリを運用に使わない

2026年9月1日にオーナーから確定した指示である。要旨を記す。

• AquaDraftのリポジトリはアプリ本体のためのものであり、アプリそのものに関係しないものは一切置かない
• 理由はセキュリティと管理の両面である
• 自動化はあくまで運用の話であり、アプリ本体とは無関係である
• 今回の自動化の運用ではリポジトリを使わなくてよい
• 運用の記録が要るなら、手元にログとして残せばよい

これは設計に直接効く。運用の状態、候補素材の一覧、実行ログ、テストの結果は、いずれもリポジトリの外に置く。コードの変更をきっかけに動く仕組み(GitHub Actions)も、運用の実行の場としては採用しない。アプリのコードに対する既存のテスト設定は、アプリ側の設備としてそのまま残す。

2.6 状態の置き場

置き場は三つに限定する。

3. 使う機能と使わない機能

3.1 使う機能

3.2 使わない機能と理由

4. 業務別の設計

4.1 表の読み方

以下、業務ID順に全18業務を工程まで分解する。各表の列は次の意味である。

• 担当は、その工程を誰が実施するか。Claude、機械(判断を伴わない自動処理)、オーナーの3種類
• 評価は、要件定義書2.2のAI評価カテゴリ。高信頼、中信頼、低信頼、自動化禁止
• 分類は、要件定義書2.3の自動化分類。Aは完全自動化、Bは下書きの後に承認、Cは条件超過時のみエスカレーション、Dは人間確認必須、Eは自動化しない
• 使う機能は、その工程を動かす機能の名前。名前は5章の一覧と一対一で対応する
• 整備状況は、その機能の現状

使う機能の列は、必ず名前まで書く。頭に付く語が機能の種類であり、同時に実行の場を示す。定期タスクとフックは無人で起動する。スキルとスクリプトは、呼ばれて動く中身である。

整備状況の語は以下のとおり使い分ける。道具があることと、無人で起動することは別である。この2つを1語で表すと実態がぼやけるため、分けて書く。

4.2 BIZ-01 素材追加

現行13工程のうち9工程をオーナーが担っている。本プロジェクトで最も改善余地の大きい業務であり、Phase 1の対象である。

工程1から3は、道具はできているが起動する仕掛けが無い。つまり私かオーナーが呼ばなければ動かない。工程13は、ブログへの投稿はできるが、SNSの認証が無いため媒体によっては投げられない。

4.3 BIZ-02 不具合修正

検知経路がオーナーの目視のみである点が最大の弱点である。利用者からの報告経路は、BIZ-18と共通の受付経路に依存する。

4.4 BIZ-03 UI改修・機能追加

2026年7月末で機能とUIは一段落しており、現在の発生頻度は低い。要望の集約経路が無いため、次の改修の起点が存在しない状態である。

定期タスクは2026年9月2日に登録した。ただし工程1が拾う先の受付経路は決まっていないため、この工程だけは動かしても要望を集められない。受付経路が決まるまで決定待ちのままである。

4.5 BIZ-04 課題・改善案の管理

記録がコミットメッセージのみであり、意思決定の経緯が追跡できない。運用でリポジトリを使わない決定により、置き場は手元のログと運用ボードになる。

4.6 BIZ-05 告知(SNS)

3媒体とも配信の認証を持っていない。文面を作るところまでは自動化できるが、投げる先が無い。

4.7 BIZ-06 ブログ記事作成

本シリーズを含め、既に回っている業務である。投稿の経路と認証が手元に揃っているため、18業務のうち最も自動化が進んでいる。

工程1は、版数1.1の時点では手順の下書きだけがあり登録していなかった。2026年9月2日に登録し、毎週日曜の朝に自動で起動するようにした。

4.8 BIZ-07 アクセス解析の確認

数値の取得手段が決まっていない。ここが決まらないと、BIZ-06の工程4も止まる。

4.9 BIZ-08 本番反映

要件定義書3.1で自動化の例外として固定した業務である。失敗時に復旧できないため、人間を残すこと自体が合理的な判断である。

4.10 BIZ-09 運用状態の把握

18業務のうち、無人で起動する仕掛けが揃っている唯一の業務である。ただし、起動しても運用ボードが更新されない事象が発生しており、原因は未解明である。9章に未決として記す。

4.11 BIZ-10 セキュリティに関わる変更

要件定義書3.1で自動化しないと固定した業務である。工程を分解しない。

4.12 BIZ-11 ユーザー投稿レイアウトの受付・審査・掲載

受け口がメールのみで、応募を貯める仕組みも状態を追う仕組みも無い。見落とすと応募そのものが失われる。

4.13 BIZ-12 多言語コンテンツの維持

多言語プラグインが無いため、記事1本につき日英2本の複製が手作業で発生している。まず日英の対応台帳が無いことが問題であり、そこから作る。

4.14 BIZ-13 辞典記事の維持

34本の記事がタイトルに価格を焼き込んでいる。価格の自動取得は禁止しているため、更新手段が存在しない。方針の決定が要る。

4.15 BIZ-14 ヘルプページの追随

機能追加のたびに日英2枚の更新が必要だが、業務として定義されていない。最終更新は2026年7月9日である。

4.16 BIZ-15 分類の整理(カテゴリ・タグ)

公開中の記事が意図しない分類に入っている。公開物の変更であるため、抽出は自動でも、適用の前に人間確認を挟む。

4.17 BIZ-16 依存パッケージの更新と脆弱性対応

2026年8月30日の見直しで追加した業務である。現在は実施していない。脆弱性が公表されても気づく経路が無いため、発生時点の報告を義務とする。

4.18 BIZ-17 バックアップと復旧

同じく2026年8月30日の追加である。リポジトリの履歴以外にバックアップが存在せず、復旧手順も定義されていない。取得先の決定が要る。

4.19 BIZ-18 一般の問い合わせ対応

同じく2026年8月30日の追加である。掲載応募以外の窓口が存在しない。BIZ-11の応募窓口とは別の経路である。

5. 機能の設定

5.1 この章の読み方

4章の各行は、使う機能を名前で指している。その名前は本章の一覧に一つずつ載っている。工程から機能を引くときは4章を、機能から工程を引くときは本章を見る。どちらからも辿れるようにするのが本章の役目である。

本章の各表には「担う工程」の列がある。ここに、その機能が受け持つ工程を全部書く。4章に書いてあって本章に出てこない機能や、本章にあって誰も使っていない機能は、存在してはならない。網羅の確認は5.9に記す。

2.1に記した三つの軸との対応は次のとおりである。

5.2 定期タスク

曜日と時刻で自動的に起動する。オーナーの操作は要らない。無人で回るかどうかは、この表がすべてである。

2026年9月2日、オーナーの承認により8件すべてのスパンと起動時刻を確定し、登録を終えた。

スパンの決め方

中身がどれだけ速く変わるかで決めた。毎日動かす理由のあるものは一つも無い。

週次に置いた5件は、1週間あれば見るべき差が出る。訳文の抜け、公表された脆弱性、失敗の記録、記事のネタは、いずれも週の単位で溜まる。

月次に置いた3件は、1週間では差が出ない。素材候補は、2026年8月29日から9月1日の4日間で3カテゴリを調べたが、素材として登録まで進んだのは2件である。調べる速さより取り込む速さのほうが遅く、週次にしても候補が積み上がるだけになる。回帰テストは素材を1件足すたびに通し実行の最後で自動的に走るため、定期の側は放置による腐りを拾う役割しか持たない。バックアップは、月1回でよいとオーナーが決めた。

日曜の朝に寄せた理由

読む場所は運用ボード1つ、読む日は日曜1日に揃える。8件を曜日で散らすと、オーナーが週に何度もボードを見に行くことになり、自動化した意味が薄れる。

日曜の朝は実績もある。週次の運用レポートは、この時刻に実際に起動している。

月次の3件も日曜に置いた。オーナーが日曜にパソコンを開いていれば、その日のうちに8件すべてが片づく。

月次をどう実現したか

cronは日付の指定と曜日の指定を「または」で読むため、毎月最初の日曜を式だけで書くことはできない。1日から7日までと日曜を並べて書くと、日曜以外の1日から7日にも起動してしまう。

そこで月次の3件も式は毎週日曜とし、中身の先頭で今日が1日から7日のあいだかどうかを判定させた。あてはまらない週は何もせずに終える。ログにも書かない。

書き込み先の分担

運用ボードへ書くのは、週次の運用レポート1件だけである。残りの7件は手元のログまでしか書かない。

同じページを複数のタスクが同時に書き換えると、後から書いたほうが前の内容を消す。ログは追記しかしないため、これが起きない。5.7に記した「手元のログはClaudeが読むもの、運用ボードはオーナーが読むもの」という分担とも合う。

順序は時刻で作った。収集の3件が先に走ってログへ書き、08時台の運用レポートがそれを読んでボードを書き、最後に記事計画がその朝の材料を使って案を出す。

起動時刻の端数について

表に書いた時刻は、指定した時刻に数分の幅を加えたものである。同じ時刻に一斉に起動しないよう、タスクごとに自動的にずらされる。順序が入れ替わらないよう、隣り合うタスクの間隔は10分以上とった。

パソコンが閉じていた場合、起動は取りこぼされない。次にパソコンとClaude Codeを開いた時点で走る。

5.3 スキル

手順を固定して、毎回同じ順序で実施させるための中身である。定期タスクから呼ばれたときも、会話の中で呼んだときも、同じ手順が走る。

スキルは現在、1つずつ独立して置いている。複数をまとめて配布する単位(プラグイン)は作っていない。数が増えて差し替えの単位をそろえる必要が出た時点で作る。前版でこれを作成済みと書いたが、誤りである。

5.4 フック

特定の操作の直後に自動的に走る。人が忘れても記録が残る点に価値がある。本設計では、記録の取りこぼし防止にのみ使う。

判断を挟む処理はフックに載せない。動作が止まる原因になるためである。

5.5 手元の道具

判断の要らない機械的な処理は、スクリプトとして手元に置く。運用の道具であり、AquaDraftのリポジトリには入れない(2.5)。

素材追加の道具は、アプリのリポジトリに入る設定ファイルを汚さないため、パッケージ管理の登録名を持たない。呼び出しは実行環境から直接行う。スキル「素材追加」に書いてある呼び出し方が実物と食い違っているため、9章に未決として記す。

5.6 共通機能「即時報告」

発生した時点でオーナーへ報告する義務のある工程が3つある。BIZ-16の工程5、BIZ-17の工程5、BIZ-18の工程6である。3つとも同じ仕掛けを使う。

週次のまとめを待たずに出す点が、運用レポートとの違いである。

5.7 状態の置き場

手元のログは私が読むためのもの、運用ボードはオーナーが読むためのものであり、役割を分ける。運用ボードへ書くのは週次の運用レポート1件だけとし、残る7件の定期タスクは手元のログまでにとどめる。同じページを複数のタスクが同時に書き換えると消し合うためである。なお、定期タスクが起動しても運用ボードが更新されない事象が出ていた。原因は無人実行が権限の確認で止まることであり、9章に未決として記す。

5.8 認証情報

WordPressへの接続、投稿の経路、その他の認証は、手元の環境ファイルで一元管理する。値は本書にも記事にも会話にも出さない。クラウドからは読めないため、認証を要する処理はすべて手元で動かす。

5.9 網羅性の確認

4章の表に並ぶ行は、廃止した1行を除いて93である。この93行のうち、使う機能の列が空欄のものは無い。名前が入っていない行は次の3種類しかなく、いずれも全数を別の章に挙げてある。

残る62行は、すべて5.2から5.7のいずれかの名前を指している。逆に、5.2から5.7に載せた機能で、担う工程が空のものは無い。

オーナーが担う工程は6章のとおり16ある。上の表で15になっているのは、BIZ-11の工程6だけ下書きをスキルが担い、送信だけがオーナーに残るためである。前提が決まらない7行は、7章に挙げた7件の前提と一対一で対応する。

両方向で辿れることをもって、機能と工程が紐づいたとする。

6. 人間に残る工程

「Claudeがやるのか、オーナーしかできないのか」を全工程で確認した結果、オーナーに残る工程は以下の16である。これ以外の工程はすべて、私または機械が担う。

これに加えて、BIZ-01の工程4で使う情報の取得経路は、オーナーの承認したものに限る。経路そのものの承認は既に得ている。

残る工程の性質は3つに分かれる。取り返しのつかない操作、外部への送信、そして製品の方向を決める判断である。この3つ以外は人間に残さない。

7. 前提が解けるまで着手できない工程

4章で決定待ちとした工程を、待っている前提ごとにまとめる。いずれも「誰がやるか」は決まっており、「どこへ繋ぐか」が決まっていない。

これらは私の側で決められない。外部との接続と費用に関わるためである。決まるまでは、当該工程を含む業務のうち、前提に依存しない工程だけを進める。

8. 設計完了の判定

1.2に記した5条件に対する、本書公開時点の判定である。

5条件が揃った。これをもって自動化の設計を完了とする。ただし7章の7件は、オーナーの決定を待たなければ実装に進めない。設計としては担当と実行の場まで確定しており、接続先が決まり次第そのまま実装できる状態にしてある。

なお、本書の承認をもって設計完了とするかどうかは、オーナーの判断による。

9. 未決事項