別のレビュー役による実行可能性チェックを反映済み（08）。11月の立ち上げから年内の「どっと原価 手入力ゼロ（第1弾）」までを週単位で、そのあとの業務改善を業務ごとの手順で書いた実行計画です。WBS v1（10/25）の上に乗せて使い、決まったことはWBSに戻してください。
役員会（10/19）で「タカラ住建のどっと原価をはじめとした手入力作業を年内になくす」と宣言済み。最初の成果はここで出し、その実績を使って121件に広げます。
次の4つが期日までに決まらないと、どっと原価の年内切り替えは間に合いません。期日を過ぎたら「年内の範囲を縮める」と先に合意しておきます。
| 期日 | 決めること | 決める人 | 遅れたとき |
|---|---|---|---|
| 10/31 | どっと原価の版（オンプレ／クラウド）と、原価実績を取り込む機能の有無。建設ドットウェブとタカラ住建の情報システム担当に問い合わせる | 船津・タカラ住建 | レシピAの方式を代案（手順4の(3)）に切り替える |
| 10/31 | 両社のAI担当者（各1名）と、その代わりを務める人 | 小林部長 | キックオフとセットアップが後ろにずれる |
| 11/6 | タカラ住建のClaude契約と組織（独自に持つか、同じ組織に入るか）。原価データを置く場所と、会社をまたぐ共有の承認 | アミリタHD（ライセンス整備はお客様側の作業） | WEEK2のセットアップと書類の受け渡しができない |
| 11/20 | 「手入力ゼロ」の定義と年内の対象（どの帳票、月何件）を書面で合意し、役員に報告 | 八田・小林部長 | 年末に「約束と違う」評価になる |
担当の色：LIDDELL アミリタ様 両社。日付は提案で、キックオフ日程（要確認No.1）が決まったら前後にずらします。
12月は Sprint 3（11/30〜）で並走、Sprint 4〜5 で手入力から切り替え、年末休み前に第1弾を完了させる想定です。12月は入力担当が年末で忙しく、並走は作業が二重になるため、並走は1週間・件数を絞って行います。タカラ住建の年末休業日はキックオフで確認します。
10/14は社長のSub PC（メモリ95%）とテザリングで中断しました。同じことを起こさないため、事前チェックを必ず先に回します。
ライセンス購入と組織の整備は契約の対象外で、お客様側の作業です。LIDDELLは手順の案内まで行います。
画面の名前はアプリの版で変わります。当日は実画面で確認します。
| 時間 | やること | 確認ポイント |
|---|---|---|
| 0–10分 | 目的と今日のゴール。「1年後に自分で業務を直せる人」になる道筋を説明 | 担当者が自分の業務の困りごとを1つ言える |
| 10–25分 | Claudeデスクトップアプリを入れ、会社のTeamでログイン | 左下の名前で所属がTeamになっている（個人用ではない） |
| 25–40分 | Claude in Chrome を Chrome ウェブストアから追加 → ログイン → ピン留め → 権限を許可。デスクトップ側は 設定 → コネクタ で Claude in Chrome をオン | Chrome右上から開け、「このページを要約して」が動く。会話ごとにオンにする必要があることを理解 |
| 40–55分 | コネクタ接続：Gmail、Googleドライブ、Googleカレンダー（Slackは使う会社のみ）。読み取り系は「常に許可」 | 「昨日届いたメールを3行で」が動く |
| 55–75分 | スキルの説明（10分）：スキル＝手順書。SKILL.md（常に読む短い核）と reference/（必要時だけ読む資料）。中尾社長AIを実例として見せる。 その場で練習：「議事録を決定事項・宿題・期限の表にする」スキルを一緒に作る | 自分の会話で「/」から作ったスキルを呼び出せる |
| 75–85分 | スケジュールタスクの見せ方：毎朝のメール要約を1本予約（PCを閉じていてもクラウドで動く。PC内のファイルを使う作業は除く。Chromeのショートカットの定期実行はChromeが起動している必要がある想定で設計する） | 翌朝、結果が届く。失敗したときの通知先を決める |
| 85–90分 | 宿題：自分の業務を3つ、「いつ・何を見て・何を入力するか」で書き出す | 次回レクチャーの題材になる |
毎回「その週に船津が作ったもの」を教材に使い、宿題で担当者自身に手を動かしてもらいます。最初の12回で「自分で1本作れる」ところまで行き、2月末の効果確認に合わせます。受講者は契約どおり各社1名で、2名以上は別見積です。
チャット／Cowork、コネクタ・スキル・プロジェクト・スケジュールタスク
目的・材料・出力形式・確認方法の4点。悪い例と良い例
ページを読む・まとめる・フォームに下書きする。最後のボタンは人が押すルール
どっと原価の読み取りスキルを開いて構造を説明
業務棚卸し → 手順の分解 → 判断ポイントの抜き出し
手順書から SKILL.md と reference/ を作る
Gmail・ドライブから材料を探させる。権限の考え方
定期実行の設計。失敗時の通知、ローカルファイルを使う作業との違い
Claude in Chrome のショートカット保存と定期実行
ズレメモ、CHANGELOG、版数。前の版に戻す
スキルの共有、使い方の説明、問い合わせ対応
作ったもの・削減時間・次にやりたいことを小林部長に発表
担当者が自分で作った・直したスキルを毎週持ち込み、八田が添削。3月以降は担当者がバックログの1本を自分で担当
契約上は年間約48回です。年末年始など休みの週は回を飛ばし、翌週に詰めません。第11回の「社内共有」は担当者の同僚1人への説明までで、説明会や運用マニュアル作成は対象外です。
どの業務を「どの道具で、どの順に、何を測って」変えるか。現状の欄は聞き取り前の仮説を含むので、ヒアリング後に書き換えます。
genka-yomitori が工事名・業者・科目・金額・日付を読み取り、工事マスタと突き合わせて表にする工事マスタはどっと原価から書き出したファイルを reference/ に置く手書き伝票の読み取りと、工事への紐付けは人の判断が残る前提で設計する。「手入力ゼロ」は「書類を見て打つ作業ゼロ（照合と登録ボタンは人）」と定義し、11/20までに書面で合意する。テスト環境がなければ、並走中は登録前の表で差分を確認し、本番への登録は手入力分だけにする。
/kian-check。出力は「足りない情報」「社長が聞きそうな質問」「方針とのズレ」の3つ開始条件は「中尾社長AIが毎朝更新されている」「社長が判断基準を社員に共有してよいと承認した」の2つ。最終判断は社長で、AIの出力は「判断材料」と明記する。
mitsumori-kabeuchi：案件概要を入れると、前提チェックリストと「過去の似た案件」を返すbukken-keisai：物件概要から紹介文・掲載項目表・チェックリストを作る着手前に各ポータルの利用規約で自動入力が禁止されていないか確認し、管理画面を許可サイトに登録する。図面・パースの画像編集そのものは別ツールが必要な場合があるので、最初は文章と入力作業に絞る。
Slackの社内利用は止まっているため、最初はメールかドライブを材料にする。Slackを使う場合は、ワークスペース管理者によるコネクタの承認が要る。
月10時間／社は、月4.3週で割ると週に約2時間15分です。会議は定例30分だけにまとめ、残りを構築に回します。
| 場 | 時間 | 中身 |
|---|---|---|
| 定例（振り返り＋計画） | 30分 | デモ、削減時間、次の1本 |
| 構築・組み込み | 約85分 | 船津が作り、担当者と15分で動作確認 |
| 相談・効果測定 | 約20分 | チャット対応、前後の時間の記録 |
| 軸1 レクチャー | 60分 | 八田。軸2の時間とは別枠 |
定例とレクチャーを同じ曜日に続けて置くと、担当者の拘束が半日に収まります（要確認No.5）。
一覧に4列を足して点数化し、上から取ります：月間工数（大きいほど上）、頻度（毎日＞毎週＞毎月）、1スプリントで収まるか、担当者が後で直せるか。週1本のうち大きいものは数週に分かれるので、LIDDELLが作れるのは2社あわせて年30〜40本が現実的な線です。残りは「やらない」か「担当者が自分で作る」に振り分けます。
| リスク | 対策 | 担当 |
|---|---|---|
| 担当者が休む・異動する | 各社に代わりの人を1名決め、定例の議事録とスキルの説明文を共有しておく | 小林部長 |
| 自動化が誤った結果を出す | 本番に入れる前に戻し方を決める（前の版のスキルに戻す、手作業に戻す手順） | 船津 |
| スケジュールタスクが失敗する | 失敗時の通知先を担当者と船津の2人にする。週次定例で実行履歴を確認 | 船津・担当者 |
| 年末・決算期で現場が忙しい | 12月の並走は1週間・件数を絞る。年末休業の週はスプリントを休む | 八田 |
| 軸2の時間を超える | 超えそうな時点で定例で報告し、翌月に回すか追加工数かを小林部長と決める | 船津 |
| 作業 | 区分 |
|---|---|
| 初期セットアップ（各社1回） | 初期費用 |
| キックオフ、ヒアリング、構築、定例、効果測定 | 軸2（月10時間／社） |
| レクチャー、宿題、チャットサポート | 軸1（週1回60分、各社1名） |
| 中尾社長AI 研修（全3回） | 別トラック（八田・萩原）。扱いを社内で確認 |
| ライセンス購入・組織の整備、運用マニュアル、説明会、2人目以降の受講者 | 対象外（お客様側または別見積） |
WBSの候補（会議体タブ）に目標値と測り方を付けた案です。基準値はWEEK 2のヒアリングで取ります。
| 軸 | 指標 | 測り方 | 頻度 | 2月末（案） | 10月末（案） |
|---|---|---|---|---|---|
| 軸2 | どっと原価の手入力件数 | 月の入力件数のうち、人が書類を見て打った件数 | 月次 | 第1弾の対象 0件 | 対象業務すべて 0件 |
| 軸2 | 本番で使われている自動化の本数 | 「完了」の定義を満たしたもの（2社計）。消化ポイントと並べて見る | 週次 | 6本 | 30本 |
| 軸2 | 削減時間 | 導入前の時間 − 導入後の時間（時間／月、2社計） | 月次 | 基準値の後に設定 | 基準値の後に設定 |
| 軸1 | 宿題の完了率 | 出した宿題のうち期限内に終えた割合 | 週次 | 80%以上 | 80%以上 |
| 軸1 | 担当者が自分で作った・直したスキル | 船津が手を入れていないもの（1社あたり） | 月次 | 1件 | 5件 |
| 社長AI | 「自分らしさ」の自己採点 | 中尾社長が100点満点で採点 | 月次 | 80点 | 90点 |
| 社長AI | 社員の利用回数 | 起案チェック（レシピB）で社員が使った回数 | 月次 | 開始後に設定 | 開始後に設定 |
| 共通 | 消化ポイント | スプリントごとの合計 | 週次 | 記録を始める | 安定 |
本数の目安は、タカラ住建が12月中旬までどっと原価に専念し、実質の構築期間が2月末まで約10週になる前提です。投資額（税別380万円／年）に対し、削減時間×時給で「何ヶ月で元が取れたか」を月次で見せると、9/30の更新判断の材料になります。
初稿を、公式ヘルプと契約条件に照らして別のレビュー役（Claudeの独立したレビューエージェント）に確認させました。NG 5件、条件付き 8件の指摘があり、下のとおり本書に反映済みです。「残る条件」は計画だけでは消せないので、期日までに確認します。
どっと原価で取込が確認できるのは予算データだけ。オンプレ版はClaude in Chromeで操作できない
直したこと版と取込機能を10/31に問い合わせ。オンプレ版の代案を手順4(3)に追加
残る条件取込不可のオンプレ版なら、年内は「転記用の表」までになる可能性
11〜12月のタカラ住建の作業が月10時間を超える
直したことレシピBを1月へ移動。週の時間配分を再計算。超過時の扱いを明記
残る条件超過分の扱いを小林部長と合意
担当者・ライセンス・方式・範囲が決まる期日がない
直したこと01にクリティカルパスの表を追加
残る条件期日に遅れたら範囲を縮める合意
タカラ住建の原価データを扱う組織と承認が未定
直したこと11/6の決定事項に追加。要確認No.7を承認手続きに格上げ
残る条件アミリタHDの判断
代わりの担当者、戻し方、失敗通知、年末休業が抜けている
直したこと06に「止まらないための決めごと」を追加
残る条件年末休業日の確認
正答率99%は30件で検証できず、手書きでは楽観的
直したこと指標を「確定データの誤り0件」に変更。金額は全件照合、合計・税額を自動検算
「手入力ゼロ」の定義が宣言とずれる
直したこと定義を明記し11/20に書面合意。WEEK4の表現を修正
残る条件役員への報告
レクチャー12回で終わり、契約の約48回と合わない
直したこと13回目以降の添削・自走を追加。受講者は各社1名と明記
ライセンス整備・説明会など対象外の作業が混ざる
直したこと費用の区分表を追加
残る条件社長AI研修の費用区分を社内で確認
Coworkの有効化が漏れている。Chromeの定期実行はChrome起動が前提
直したこと管理者設定とセットアップ手順に追記
残る条件毎朝の更新がクラウドで動くかを初日に試す
週報はSlack前提だが社内で使われていない
直したこと材料をメール・ドライブに変更
起案チェックは社長AIの完成と共有承認が前提。ポータルは規約確認が必要
直したことレシピB・Dに開始条件を追加
残る条件社長の承認、各ポータルの規約
本数の目標（2月末10本）が工数に対して高い
直したこと2月末6本・10月末30本に修正。社員の利用回数を追加
残る条件基準値を取ってから再確認
確認した機能の前提：Claude in ChromeはChrome専用でTeamでは既定で有効、許可・禁止サイトを設定できる。スケジュールタスクはPCを閉じていてもクラウドで動くが、PC内のファイルやアプリを使う作業は除く。スキルは組織設定でSkillsとコード実行を有効にする必要がある。