デザインレビューの指摘事項管理表をClaudeで作る — 議事メモから未完了の抽出まで

デザインレビューの議事メモは、読み返すと「誰が何を言ったか」の記録になっています。次回に要るのは「誰がいつまでに何をするか」で、この2つは別物です。

そこで議事メモを、指摘・担当・期限・処置結果の列を持つ管理表に直します。Claudeに任せるのは、発言から指摘を切り出す作業と、次回の議事メモを前回の表に突き合わせる作業です。期限の比較は手元のスクリプト、設計変更が済んだかどうかの判断は人が持ちます。手順は、列を決める、Projectsに置く、切り出す、未完了を引く、次回と突き合わせる、の順です。

管理表の列は次回レビューの質問から決める

列は「次回レビューの冒頭で何を聞くか」から逆算します。聞くことは3つに絞れます。

• 前回の指摘のうち、まだ終わっていないものはどれか
• 期限を過ぎているのは誰の、どの項目か
• 終わったと報告された項目は、何で終わったと言えるのか

この3つに答えられる列を置くと、次のようになります。

「担当」と「期限」は空欄を許します。レビューの場では、誰がやるかも、いつまでかも決まらないまま次の議題に移る指摘が出るからです。空欄を埋めるために推測させると、次回に「そんな期限は決めていない」と揉めます。空のまま残し、次回の冒頭で決める項目として並べるほうが、議事メモの実態に合います。

「原文」の列は、後から指摘の趣旨を確かめるための保険です。要約が元の発言からずれていたとき、人が見比べて直せます。

Projectsに置くものと、置いても効かないもの

同じレビューは複数回続くので、材料をProjectsにまとめます。プロジェクトは、チャット履歴と知識ベースを持つ独立した作業場です。知識ベースに入れたものは、そのプロジェクトのすべてのチャットで使われます。

置くものは3種類です。

• 管理表の最新のCSV（ファイル名に日付を入れ、最新の1つだけを置く）
• 列の定義と区分の判定基準を書いた1枚のメモ
• 設計仕様書やレビュー対象の図面一覧など、指摘の対象を特定する資料

プロジェクトの指示（Set project instructions）には、振る舞いのルールを書きます。例えば次のような内容です。

あなたはデザインレビューの指摘事項管理表を保守する補助者です。
- 議事メモの発言は「指摘」「議論」「決定」「雑談」に分け、
  指摘だけを管理表の行にする
- 担当と期限は、発言に明示されたものだけを書く。無ければ空欄
- 状況を「完了」にしてよいのは、処置内容と確認日が
  メモに書かれているときだけ。それ以外は変えない
- 既存の指摘と同じ内容は新しい行にせず、既存のIDを示す
- 出力は管理表と同じ列のCSV。要約した箇所には原文を残す

注意点が2つあります。

1つ目は、プロジェクトの名前と説明です。作成時に入力する名前と説明は、Claudeには見えません。ルールをそこに書いても効かないので、ルールは指示かファイルに置きます。

2つ目は、チャット間の共有です。プロジェクト内でも、チャットの文脈は知識ベースに追加した情報しか共有されません。ある回のチャットで更新した管理表は、CSVとして保存し、知識ベースに置き直して初めて次のチャットで使われます。更新を忘れると、次回のClaudeは古い表を前提に答えます。

ファイルの扱いにも条件があります。プロジェクトのファイルは1つ30MBまでで、文書は文字の抽出だけが行われます。図面の画像に書かれた寸法や注記を読ませたいときは、チャットに直接添付するほうが向きます。なお、Excelのファイル（XLSX）を上げるには、アカウント側でコード実行とファイル作成を有効にする必要があります。CSVならその設定なしで扱えるため、この記事は管理表をCSVで持ちます。

手順1: 議事メモを指摘事項に切り分ける

議事メモの元になる文字起こしは、録音から作るのが速い反面、発言者の名前が崩れていることがあります。ツール選びはClaudeの議事録ツール比較にまとめてあります。ここでは、すでに議事メモの文字が手元にある前提で進めます。

第1回の議事メモをチャットに貼り、次のように頼みます。

添付の議事メモは第1回デザインレビューの記録です。
管理表の列（ID,レビュー回,指摘内容,区分,対象,担当,期限,
状況,処置内容,確認日,原文）に合わせたCSVにしてください。
 
- IDは DR01-01 から連番
- 状況は初回なので全て「未着手」
- 指摘にならない発言（質問への回答、雑談）は行にせず、
  末尾に「行にしなかった発言」として一覧にする
- 担当・期限は発言にあるものだけ。推測しない

「行にしなかった発言」を出させるのは、切り捨てた中に指摘が混ざっていないかを人が確かめるためです。「ここは変えたほうがいいかもね」のような曖昧な発言は、指摘か雑談かで読み手によって割れます。判断が割れた発言を見える場所に置くと、確認が1か所で済みます。

出力は、例えば次のような形になります。内容は説明用の例で、実際の出力は議事メモによって変わります。

ID,レビュー回,指摘内容,区分,対象,担当,期限,状況,処置内容,確認日,原文
DR01-01,第1回,筐体の嵌合部に抜き勾配が不足している,必須,筐体上カバー 図番A-100,設計A,2026-10-20,未着手,,,"抜き勾配、1度じゃ足りないですよね。2度は欲しい"
DR01-03,第1回,放熱の実測値を次回までに出す,必須,電源部,設計B,2026-10-15,未着手,,,"放熱は実測ください。次回までで"
DR01-04,第1回,コネクタ位置の変更可否を営業に確認する,確認,I/O面,,,未着手,,,"コネクタ位置は営業に聞いておきたい"

DR01-04は担当も期限も空欄のままです。これで正しい出力です。この行は、次回の冒頭で「誰が、いつまでに」を決める項目として表に残ります。

出力のCSVは必ず人が一度読み、指摘内容が原文と食い違っていないかを見ます。見終えたら、ファイルに保存して知識ベースに置きます。

手順2: 未完了と期限超過は日付計算を手元で

次回レビューの前に欲しいのは、未完了の一覧です。ここはClaudeに日付を比べさせず、手元のスクリプトに任せる運用が確実です。「期限を過ぎているか」は、基準日を決めれば機械的に決まります。文章で答えさせると、数え間違いが静かに混ざります。

次のスクリプトは、管理表のCSVと次回レビュー日を受け取り、状況が「完了」「取り下げ」以外の行を期限順に並べます。

import csv, sys
from datetime import date
 
DONE = {"完了", "取り下げ"}
 
def main(path, review_date):
    today = date.fromisoformat(review_date)
    rows = list(csv.DictReader(open(path, encoding="utf-8")))
    open_rows = [r for r in rows if r["状況"] not in DONE]
    print(f"次回レビュー日 {today} 時点の未完了:"
          f" {len(open_rows)}件 / 全{len(rows)}件")
    for r in sorted(open_rows, key=lambda r: r["期限"] or "9999-99-99"):
        due = r["期限"]
        if not due:
            tag = "期限未定"
        elif date.fromisoformat(due) < today:
            tag = f"期限超過({(today - date.fromisoformat(due)).days}日)"
        else:
            tag = "期限内"
        print(f'{r["ID"]} [{tag}] {r["担当"] or "担当未定"}'
              f' / {r["状況"]} / {r["指摘内容"]}')
 
if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

DR01-01が完了、DR01-02が対応中、DR01-03とDR01-04が未着手の4行の表で、次回レビュー日を2026-10-27として動かします。

python3 open_items.py review.csv 2026-10-27

出力は次のとおりです。

次回レビュー日 2026-10-27 時点の未完了: 3件 / 全4件
DR01-03 [期限超過(12日)] 設計B / 未着手 / 放熱の実測値を次回までに出す
DR01-02 [期限超過(2日)] 設計B / 対応中 / 基板固定ねじの数を減らせないか検討する
DR01-04 [期限未定] 担当未定 / 未着手 / コネクタ位置の変更可否を営業に確認する

この出力を次回レビューの冒頭資料に貼れば、「期限超過は2件、担当未定が1件」と一目で言えます。期限未定の行を最後に並べているのは、期限のある行を先に片付けるためです。同じ型の期限管理は、有期契約の更新管理表でも日付計算をスクリプトに寄せています。

手順3: 次回の議事メモを前回の表に突き合わせる

第2回の議事メモが上がったら、前回の管理表と一緒に渡します。ここでClaudeに頼むのは、新規の指摘を切り出すことに加えて、既存の指摘への言及を見つけることです。

添付は管理表（review_2026-10-13.csv）と第2回の議事メモです。
議事メモの発言を、次の3つに分けて表にしてください。
 
1. 既存の指摘への進捗報告（該当IDを示す）
2. 既存の指摘への追加・変更（該当IDを示す）
3. 新規の指摘（IDは DR02-01 から連番）
 
- 状況の変更は「案」として出す。完了にしてよいかは判断しない
- 処置内容と確認日がメモに無い報告は、状況を対応中のままにする
- どのIDにも当てはまるか迷う発言は、候補のIDを並べて人に戻す

3分類にする理由は、ここで一番起きやすい失敗が「同じ指摘の二重登録」だからです。第1回の「放熱の実測値」に対して、第2回で「放熱の件、結果が出ました」と言われたとき、新しい行にせず既存のDR01-03に紐づける必要があります。指示に「既存のIDを示す」と書いておくと、紐づけを間違えたときに、人がIDを見て気づけます。

分類の結果は、管理表に反映する前に人が見ます。反映後のCSVを新しい日付のファイル名で保存し、知識ベースの古いファイルと入れ替えます。

「完了」を誰が決めるか

管理表で一番揉めるのは、状況が完了かどうかです。担当者の「直しました」と、指摘した側の「確認しました」は別の事実で、前者だけで完了にすると、図面が改訂されていないのに表だけ閉じる事態が起きます。

そこで、列と運用を次のように分けます。

プロジェクトの指示に「処置内容と確認日が揃うまで完了にしない」と書いておくと、Claudeは完了への変更案を出す前に、不足している列を指摘してくれます。ただし、設計変更が実際に反映されたかは、改訂後の図面で人が確かめる事柄です。Claudeが議事メモの文面から判断できるのは、報告があったかどうかまでです。

設計変更の追跡という点では、変更申請の作成を支えるCoworkのoperationsプラグインを扱った運用手順の記事が別の入口になります。こちらの管理表は、レビューの議事メモを起点にした指摘の台帳です。

共有するときの権限と、つまずきやすい点

レビューに複数人が関わるときは、プロジェクトを共有する選択肢があります。共有はTeamプランとEnterpriseプランの機能で、管理者が共有を止めていると使えません。権限は2段階です。

管理表のCSVを更新する人は編集権限、指摘の内容を確かめるだけの人は閲覧権限、という分け方が使えます。

つまずきやすい点は次のとおりです。

• 古いCSVが知識ベースに残る。日付入りのファイル名で、最新の1つだけを置く運用にします。
• IDの振り直し。行を消して連番を詰めると、議事メモや図面の注記が指すIDとずれます。取り下げた指摘は、削除せず状況を「取り下げ」にします。
• 無料プランのプロジェクト数。無料アカウントで作れるプロジェクトは最大5つまでです。レビューの案件ごとにプロジェクトを分けると、すぐに上限に近づきます。1案件ずつ、終わったものはアーカイブして一覧から外します。
• 図面や仕様書の機密。指摘の対象特定に社外秘の図面を上げる前に、社内の情報取り扱いの規程を確認してください。

プロジェクトを閉じるときは、アーカイブを使えます。アーカイブしても共有権限やメンバーは残るため、アクセスを外したい相手は共有設定から削除します。アーカイブしたプロジェクトは削除できず、削除するには先に元に戻す必要があります。

まとめ

管理表の価値は、列の多さではなく、空欄の意味が決まっていることにあります。担当と期限が空なら次回の冒頭で決める、処置内容と確認日が空なら完了にしない、というルールを列とプロジェクトの指示に書き込むと、議事メモが変わっても同じ読み方ができます。

Claudeの役割は、発言の切り出しと既存IDへの紐づけ案までです。期限の比較はスクリプト、完了の判断は指摘した人に置くと、3者の責任が混ざりません。ここまでの流れを1回のレビューで試し、「行にしなかった発言」に指摘が混ざっていないかを確かめるところから始められます。