個別に学んだAGENTS.md、Skills、権限、差分確認を、一つの業務へつなげます。
最終課題は、架空の研修サイトの月次更新です。
新しい開催情報を受け取り、下書きを変更し、表示と内容を確かめるところまでを標準化します。
すべてを自動化する必要はありません。
誰が見ても結果を採用でき、問題が起きたら再開できる仕事の流れを完成させます。
この記事で学ぶこと
- 最小の業務で一巡させる
- 保留と完了を明確に分ける
- 実測から手順と範囲を見直す
対象と成功指標を決める
最初に、今回の業務の始まりと終わりを決めます。
入力は確定した開催情報、出力は確認済みの更新案と検証記録です。
公開は担当者の判断として別工程にします。
範囲が曖昧なまま環境を整えると、何を準備すれば終わるか分からなくなります。
1つの定期業務へ限定します。
品質条件は、日時と料金が正本に一致する、申込先が正しい、表示に欠落がない、予定外の変更がないことなどです。
これらは公開前に確かめられる条件です。
申込数が増えるかという事業上の効果は、更新後の別の観測になります。
作業の完成と期待する効果を区別して記録します。
時間は、依頼、生成、確認、修正を合計して測ります。
コードを書く時間だけ短くなっても、検証や手直しが増えれば全体は改善しません。
比較するときは同じ程度の更新内容を使います。
架空の数字で削減率を保証せず、実際の記録から継続する価値を判断してください。
更新業務の頻度と利用者への影響も記録します。
月1回の開催情報と、毎日変わる在庫では必要な運用が異なります。
この課題の手順を別の業務へ移すときは、そのまま流用せず条件を見直してください。
成功した仕組みの再利用でも、入力の変化と誤りの影響が同じかを確認します。
ルールと手順の役割を揃える
AGENTS.mdには、サイトの目的、正本、編集範囲、必要な検証、報告形式を置きます。
Skillには、月次更新の入力確認、変更、照合、出力の手順を置きます。
同じ説明を両方へ大量に重複させると、片方だけ更新されて矛盾することがあります。
共通条件と業務固有の流れは、役割を分けて記述してください。
作業フォルダには、確定情報と更新するファイルを区別して置きます。
元資料は参照し、サイトの正本を変更します。
生成されたページだけを直さないよう、出力までの関係を確認します。
開始状態と他者の変更を把握し、今回の更新だけを追えるようにします。
権限は必要な範囲へ合わせます。
ローカルの更新案を作るだけなら、外部への投稿機能は不要かもしれません。
連携を使う場合も、対象データと許可する操作を決めます。
使える機能をすべて組み込むのではなく、入力から検証までを最小の構成で通します。
正本への案内を1枚にまとめ、対象期間や版の見方も示します。
資料が増えると、同じ名称の古いファイルが混ざりやすくなります。
どれを採用し、どれを参考として残すかを明確にしてください。
AIへの指示を増やす前に、人が迷わず資料を選べる管理へ整えることが有効です。
一連の更新を実行する
標準手順では、まず確定情報の不足や矛盾を調べます。
開催日、時間、料金、対象者、申込先が揃っているかを確認します。
不足があれば、その項目を未確認として残します。
資料にない条件を過去の開催情報から勝手に補わないようにします。
過去例は参考であり、今回の正本ではありません。
次に、更新箇所を特定し、必要な変更だけを行います。
共通部品に影響する場合は、利用箇所と検証範囲を確認します。
更新案ができたら、差分と元資料を照合します。
日付や料金は1文字の違いでも業務へ影響するため、見た目の自然さより一致を優先します。
最後に、対象ページを開き、表示とリンク先を確かめます。
初めての訪問者が開催情報を理解し、申込先へ進めるかを通して確認します。
個別ファイルのチェックだけでは、画面全体の欠落を見落とすことがあります。
完成した成果物を、利用する人の順番で評価します。
変更が完了した時点で、確認済みの資料と成果物の対応を残します。
次月に開催日だけが変わるなら、どの場所へ反映する必要があるかを追えます。
前回のページを見ながら手探りで探す負担を減らせます。
ただし、古い条件を自動で引き継がず、毎回の確定資料を使うことは維持します。
不足と失敗を引き継ぐ
情報不足や検証失敗が起きたときに、何を保留し、何を進めるかを決めます。
料金が未確定なら、その箇所を確定した表現へ変えず、担当者へ確認事項として残します。
ほかの確定した文章を準備することはできます。
全体停止と部分保留を区別すると、品質を守りながら進められます。
検証が動かない場合は、環境の不足か変更による問題かを切り分けます。
未実施の確認は成功へ含めません。
記録には、保存先、変更内容、試した検証、結果、残る判断を残します。
別の人が同じ調査を始め直さなくてよい状態が、引き継ぎの合格条件です。
公開前には、具体的な更新案と検証記録を担当者が確認します。
対象と公開先が明確であれば判断できます。
公開後に不具合が見つかった場合の連絡先や復旧方針も、実務で使う段階では決めておきます。
練習の終点は更新案の完成ですが、後工程へ何を渡すかまで設計します。
不足の確認を依頼するときは、判断に必要な最小限の質問へします。
料金が未確定なら、価格と適用対象を具体的に尋ねます。
資料を全部再提出してもらう必要があるとは限りません。
どの項目が埋まれば更新案を確定できるかを示すと、担当者から必要な回答を得やすくなります。
二回の試行から改善する
1回目の試行では、手順全体がつながるかを確認します。
2回目は、情報が一部不足した見本を使い、例外の扱いを確かめます。
十分な資料で完成するだけでなく、不明な情報を断定しないことも品質です。
同じ成功例だけの反復では、例外への対応を評価できません。
記録を見て、どこに負担が残るかを判断します。
入口が分からず探索が長いなら資料の案内を直します。
料金の照合で漏れが出るなら検証表を変えます。
文体の修正が多いなら共通ルールを見直します。
原因に応じて修正する場所を選び、指示文を無制限に長くしないようにします。
見直しの担当と時期を決め、サイトや道具の仕様が変わったときにも確認します。
不要になった手順や連携は減らして構いません。
使い続ける価値は、導入した機能数ではなく、品質を維持して仕事全体を進められるかで判断します。
必要なら自動化の範囲を縮めることも改善です。
運用を広げる前に、別の担当者が同じ見本で手順を追えるかを確認します。
作った人だけが知る操作や保存先があると、引き継ぎで止まります。
説明が必要だった箇所を手順へ反映し、不要な注意は減らします。
実務環境の完成は、自分の成功だけでなく再利用できる状態までを含みます。
実践課題
実践課題：月次更新の環境を完成させる
つくるものは、月次更新の練習環境と2回分の検証記録です。
用意するのは、架空の研修ページ、確定情報、料金が不足した見本です。
これまでのルールとSkill案を使い、更新案まで通します。
公開や実際の申込受付は含めません。
- 開始と終了、品質と時間の指標を決める
- 共通ルール、入力、手順、権限を揃える
- 通常例と不足例で更新案を作り検証する
- 修正原因、残課題、見直し日を記録する
架空の完成例：「開催情報からページの更新案を作る。日付と料金を正本へ照合し、リンクと表示を確認する。料金不足の見本では該当箇所を保留にする。2回の試行で確認時間と修正件数を記録する。」
自己確認
- 入力から検証まで一巡した
- 不足情報を推測で埋めていない
- 次の担当者が結果を採用判断できる
まとめ
Codexの実務環境は、共通指示、業務手順、権限、検証を一つの仕事へ結び付けて完成します。
小さな通常例と例外で試し、確認を含む時間と品質を測ります。
次に広げる範囲は、試行で残った具体的な負担から選んでください。
- 最小の業務で一巡させる
- 保留と完了を明確に分ける
- 実測から手順と範囲を見直す
