家庭学習のキットから、更新を任せる仕組みを見る

home-learning-starter-kitは、VS Code上のAIアシスタントを管理役にして、家庭学習の計画、印刷用ワークシート、実施、記録、次の調整を続けるためのキットです。学習者・教材・テストの登録、実績の記録、週の振り返り、確認画面の生成を頼めます。

記録の本体はファイルです。Web画面はAIが更新した結果を見るための読み取り専用の静的ページで、入力フォーム・認証・クラウド同期・AIのAPIの組み込み・外部への送信機能はありません。AIを使わず、同じファイルを手で編集して運用することもできます。

ここから会社の台帳や日報へ持ち帰れるのは、家庭学習の内容ではなく、更新する決まりと、変更を確かめる手順を用意する考え方です。キットがそのまま会社の帳票や権限管理に対応するという意味ではありません。

1. 書く場所・表の列・使える値を文書にする

このキットでは、AIが作業前に共通ルールを読みます。どのファイルが正本か、何をどこに書くかは、共通ルールや記録の構成を定めた文書で管理しています。

たとえば、予定を書く表は列名と順番を変えません。状態には「予定」「完了」「一部実施」「未実施」「繰越」など、指定された値だけを使います。実績も決まった列の表に記録し、未実施や一部実施を隠さず残します。

列が毎回違うと、読む人だけでなく、後で集計したり画面を作ったりする処理も困ります。また、空欄だけでは「まだ確認していない」のか「行わなかった」のかを区別できません。状態の値を決める際は、その違いが残るようにします。

会社の業務へ置き換えるなら、少なくとも次を文書にします。

  • 保存先と正本：どのフォルダーの、どの表を更新するか。別の場所に同じ台帳を作ってよいか。
  • 形式：列名・順番・日付の書き方など、後の処理が前提にする項目。
  • 使える値：完了・一部実施・未実施・未確認など、区別する状態とその意味。
  • 人へ戻す条件：必要な情報がない、記録が食い違う、決まりの変更が必要なときの相談先。

依頼本文に目的や対応範囲をどう書くかはAIに仕事を任せる依頼、担当者の判断を聞き取って手順に残す方法はAIでマニュアルを作る手順で説明しています。この記事では、ファイル更新の前提になる保存先と形式に絞ります。

2. 変更のたびに、機械で形式と置き場所を確かめる

READMEでは、AIは変更のたびに既存の検証コマンドを実行するとしています。検証する対象は、ディレクトリ構造、正本の重複、Gitの除外、記録の入力形式、ワークシートの最小構造です。許可外の場所へのファイル作成や形式崩れは、検証で失敗する仕組みとして説明されています。

「決まりを読ませたから守ったはず」ではなく、変更した結果を確認します。会社の業務でも、保存先や列の一致、IDの重複、決めた状態以外の値など、機械で確かめられる項目を切り出す考え方が使えます。ただし、キットの検証は家庭学習用の形式が対象です。日報や在庫表には、その形式に合う確認が別途必要です。

検証に通ったことと、記録の内容が正しいことは別です。 形式が正しくても、報告された内容の取り違えや、記入漏れがあり得ます。機械で確認するのは決めた条件の範囲であり、業務上の正しさは元の報告と照合します。

検証が失敗したときは、失敗を無視して先へ進めず、変更したファイルと原因を確認します。原因の切り分けや再開の判断はAIに任せた作業が止まったときの手順へ、ツールの更新・復旧・担当交代は業務ツールの保守へ進めます。

3. 人が変更と検証結果を見てから、次へ進む

キットのチュートリアルは、初期設定から振り返りまでを1ステップずつ進めます。AIは各ステップで変更したファイルと検証結果を報告し、人が返事をするまで次へ進みません。この待機はチュートリアルの手順であり、すべての作業で自動的に承認待ちになると説明しているわけではありません。

会社で同じ考え方を採るなら、確認担当者は「成功」の一言だけで判断せず、次を見ます。

  • 指定した正本だけが更新され、関係のないファイルへ変更が広がっていないか。
  • 元の報告にある未実施・未確認が、勝手に完了へ変わっていないか。
  • 実行した検証とその結果、確認できなかった項目が分かるか。
  • 次へ進む前に、担当者の判断や追加資料が必要か。

既存の記録を移すときも、戻せる状態を先に作ります。キットの移行手順では、棚卸しと対応づけを確認し、取り込む前にスナップショットを取ります。形式が合っていても対応づけが間違う可能性があるため、取り込み後の内容確認と、元へ戻す準備を一組で考えます。

4. 実データと、公開してよいデータを分ける

キットでは実データを、Git管理から除外される専用の作業フォルダーか、リポジトリの外に保存します。公開リポジトリへ入れるのは、架空のデモや公開を許可した教材などです。

注意が必要なのは、元の記録だけではありません。自分の記録から生成した画面にも実データが含まれます。キットの生成処理では、参照する記録や教材も生成先へコピーされるため、生成HTMLや生成先のフォルダーも公開・共有しないとREADMEに記されています。

会社の業務でも、元の顧客台帳を除外したのに、確認画面や出力ファイルに顧客情報が残れば、公開用データと分けたことにはなりません。公開する候補を確認するときは、元ファイルだけでなく、そこから作った画面・添付ファイルも対象にします。

Gitの除外設定は、通常の操作で実データを管理対象へ入れないための決まりです。強制追加や設定変更までは防げません。また、一度記録されたデータは、通常のファイル削除だけでは過去のGit履歴から消えません。除外設定が効いているかと、公開候補に何が含まれるかの両方を確認します。

キットに外部送信機能がないことと、AIサービスへ情報を渡さないことも別です。AIアシスタントへ入力した内容の送信・保存・学習利用・保持期間は、各サービスの規約と設定に従います。実名を避け、必要最小限の情報を使うというREADMEの注意に加え、会社では入力を許可する範囲を先に決めます。詳しい判断は顧客情報をAIに入力する前の確認を参照してください。

想定シナリオ：日報の更新に置き換える

以下は架空の会社の日報を使った、未実施の想定シナリオです。キットで会社の日報を動かした記録や、hirosta・お客様の導入実績ではありません。

担当者の報告から日報を更新する場合、正本の保存先を一か所に決め、日付・担当ID・作業・状態・確認待ちの列を固定するとします。AIは共有を許可した報告だけを使い、「未実施」を完了へ変えず、報告にない内容は確認待ちとして残します。

変更後は、保存先・列・重複・状態の値を、その日報用の検証で確かめます。担当者が元の報告と変更内容を照合し、確認待ちが解消した範囲だけ正式な記録として採用します。形式が合わない場合や報告が食い違う場合は、その段階で止めます。

説明用の見本は架空データで作り、実際の日報と、その日報から作った確認画面は公開先へ置きません。最初に決めるのは「AIで何でも更新する」ことではなく、どの表を、どの形式で、誰が確かめて採用するかです。この例では、費用・時間・削減効果を測定していません。

よくある質問

Q. AIに決まりを読ませれば、検証は不要ですか？ 不要にはなりません。指示を理解したことと、結果が形式・保存先の条件を満たしたことは別です。変更後の検証と、人による内容確認を組み合わせます。

Q. 検証に通れば、そのまま正式な記録にできますか？ 形式や重複の確認だけでは、元の報告と内容が一致するかは分かりません。指定した変更になっているか、未確認を隠していないかを担当者が見てから採用します。

Q. 元データをGitから除外すれば、生成画面は公開できますか？ 実データから生成した画面にも、その内容が含まれます。キットのREADMEでは、その生成先も公開・共有しないよう求めています。会社の確認画面や出力ファイルも、元データと一緒に扱う範囲を決めます。

Q. このキットを会社の台帳へそのまま使えますか？ READMEの正式サポート対象はキットのstarter形式です。会社の台帳には、列・状態・保存先に合う検証や、利用者の権限などを別途検討します。この記事では家庭学習用の仕組みから、決まりと確認の考え方を取り出しています。

キットのコードはMIT License、READMEなどの文書・雛形・教材はCC BY 4.0です。この記事は公開READMEを要約し、会社の業務への考え方を追記しています。文書の帰属名義は「home-learning-starter-kit contributors」です。