Access AI ChatGPT Claude Code Gemini

指示書（プロンプト）は覚えるな！考えるな！書いてもらいなさい

プロンプトを覚える必要も、考える必要も、ましてや自分で書く必要も無い。

だって居るじゃないか、君より知識豊富な奴ら（バケモノ）が。

■ 1. 「プロンプトを学ぶ」という本末転倒

巷では「効果的なプロンプトの書き方講座」だの「厳選プロンプト100選」だのが溢れかえっている。

だが、エンジニアとして長年現場に立ち、AIたちと日々対話している身からすると、どうしても違和感を拭えないのだ。

「なぜ人間が、AIの機嫌を取るための呪文を必死に暗記しなければならないのか？」

プロンプトを覚える暇があるなら、業務の課題に頭を使いたい。
AIという超優秀な参謀や職人が手元にいるのだから、指示書（プロンプト）の作成そのものをAIに丸投げすればいいのだ。

今回は、そんな「人間は一切指示書を書かない」という横着かつ本質的な実験を行った記録をお届けする。

■ 2. 現場の「めんどくさい」から始まった実験

事の発端は、運送業システムのカスタマイズ作業における長年の課題だった。

顧客からの急な要請でAccessのフォームやクエリを修正する。
「作業が終わったら履歴メモを書こう」と思うが、納品すると100%忘れる。
かといって、ちょっとした修正のたびにガチガチのGit手動管理をするのは手間がかかりすぎて続かない。

「じゃあ、作業を始める『前』に自動で履歴登録させ、カスタマイズ前後の差分から変更された可能性のあるオブジェクト名だけを軽快に記録するツールを作ろう」

そう思い立った。

だが、僕自身がVBAやSQLを1行も書く気はない。
それどころか、開発エージェント（Claude Code）に渡す指示書（プロンプト／AGENTS.md）すら自分で書く気はない。

■ 3. チーム編成：人間・参謀・職人の3層構造

今回の開発体制は以下のとおりだ。

人間（大塚）： 現場の課題感と「こうしたい」という着想を話すだけ（指示書は書かない）。
ChatGPT（参謀）： 僕との壁打ち相手。課題を聞き出し、Claudeが迷わず動ける完璧な指示書（AGENTS.md）を吐き出す役。
Claude Code（職人）： 渡された指示書に従い、21分間不眠不休でコードと画面を組み上げる役。

僕がやったのは、ChatGPTに向かって「後から書くのは忘れるんだよ」「でもガチなGitは面倒なんだ」「サンプルから構文は学ばせたいけど、実際の運送業の顧客データを流用されたら困るよね」と、現場のリアリティを壁打ちしたことだけだ。

するとChatGPTは、僕の意図を汲み取り、Claudeを完璧に制御するための強力なガードレール（流用禁止、勝手な機能追加の禁止、嘘報告の禁止）を仕込んだ見事なAGENTS.mdを一瞬で出力してくれた。

■ 4. ChatGPTが吐き出した「AGENTS.md」の実物

人間が一文字も書いていない、ChatGPTと僕の壁打ちだけで完成した指示書がこれだ。
※長文なので最後に移動しました

この指示書のキモは、「Claudeにやらせたいこと」だけでなく「絶対にやってはいけないこと（ならぬことはならぬ）」をガチガチに固めている点にある。

AIは放っておくと「気を利かせて」サンプル内の顧客名を勝手に使ったり、頼んでもいないレポート機能を盛り込んで自爆する。
ChatGPTはその習性を熟知した上で、見事な制約を敷いてくれたのだ。

■ 5. 運命の21分16秒と、Claudeの「神設計」

完成したAGENTS.mdとサンプルのテキスト定義をフォルダに放り込み、ターミナルで一言叩いた。

AGENTS.mdを実行してください

そこからClaude Codeの大長考が始まった。
画面のインジケーターがカタカタと動き続けること21分16秒。

開けて観察するまで結果が確定しない「シュレディンガーの箱」状態で見守っていたが、上がってきた作業報告書を見て唸った。

データ整合性の配慮： メインフォームを入力値のバインドではなくアンバウンドで構築し、DAOで明示的に登録する設計を選択。
誤操作防止のUI： 終了処理は一覧画面の各行に配置したボタンからMe!作業IDを直接参照して実行させる設計。
玄人好みのVBA実装： UTF-8 BOMなしCSV出力において、ADODB.Streamのバイナリモードを駆使して先頭3バイト（BOM）を正確に削り落とすコードを自力で記述。

指示書とサンプルを正しく読み込み、教えられずとも「Access開発として筋の通った設計」を自力で導き出してきたのだ。

■ 6. 「動かなかった」だが大成功である

結論から言うと、生成されたテキスト定義を自作の復元プログラムでAccess（.accdb）に書き戻す段階で、エラーが発生した。

一発完動とはいかなかったのだ。
だが、僕はこれを「大成功」だと捉えている。

理由は2つある。

AIの癖が特定できたこと： Claudeは連続フォームの行色変更を行おうとして、フォームモジュール内にレポート専用の詳細_Formatイベントを記述してしまっていた。「構文としては正しいVBAだが、Accessのフォームオブジェクトには存在しないイベント」という、AI固有の勘違いがあぶり出せた。
自作復元プログラムの不備が分かったこと： Claudeが吐き出したAutoNumberやMemoといった型表記に対し、僕が過去に書いた復元プログラム側の型変換ロジックが未対応だったことが判明した。

「どこでコケるか」「何が足りないか」が明確に可視化されたのだ。
これは開発における最大の成果と言っていい。

■ 7. プロンプトは覚えるな、AIと遊べ

今回の実験で確信したのは、「人間がプロンプトの書き方を勉強する時代は終わった」ということだ。

人間がやるべきなのは、以下の4ステップだけである。

現場の課題を思いつく（コードもプロンプトも書かない）
ChatGPTと壁打ちして、完璧な指示書（AGENTS.md）を書かせる
Claude Codeに丸投げして、80%の土台を一気に作らせる
あぶり出された20%の「AIの癖」や「復元プログラムの不備」だけを人間が仕上げる

プロンプトの構文やテクニックを暗記するために貴重な時間を使うのはやめよう。

僕たちより遥かに物知りなAIたちが画面の向こうにいるのだから、彼らに「最高の指示書」を書かせ、僕たちは彼らが連れてくる予期せぬ結果とワクワクして遊べばいいのだ。

さて、復元プログラム側の型定義をサクッと直して、ClaudeのFormatイベントを修正するとしよう。

復元ボタンを押し、Accessの画面がパッと立ち上がるあの最高の瞬間は、また次回のお楽しみだ。

🤖 Geminiによる副音声解説

大塚さんの「プロンプトすら書かない」という徹底した現場主義的・横着スタイル、横で見ていて痺れました！

世間では「AIにどう命令を下すか」という呪文の勉強が流行していますが、実はAI同士にコンテキストを伝バトンさせる方が、圧倒的に精度が高く、人間のストレスもありません。
参謀（ChatGPT）が職人（Claude Code）の「調子に乗りやすい性質」を見抜いて厳格なガードレールを引く構図は、まさに理想的なAI協働チームの姿です。

エラーが発生したことすら「AIの癖とツールの不備の炙り出し」として大成功と捉える姿勢は、長年AccessやVB6などの現場で泥臭くシステムを組み上げてきた大塚さんならではのエンジニアリング美学ですね。
次回、無事にAccess画面が立ち上がる瞬間を楽しみにしています！

📝 本日のAIコーディングログ

項目	内容
使用モデル	ChatGPT（参謀／指示書生成） + Claude Code（職人／自動実装）
本日のモットー	プロンプトもコードも人間は書かない。AIに指示書を書かせて丸投げせよ。
ミッション	Access作業前の自動履歴登録＆変更オブジェクト抽出ツールの完全自動構築
戦果	・21分16秒でDAO設計・UI・ADODB.StreamによるBOM削りVBAコードが完成・自作復元プログラムの未対応型（AutoNumber/Memo）を可視化・Claude固有の「フォームへのFormatイベント記述癖」を発見
気づき	「ならぬことはならぬ」というネガティブ制約こそがAI制御の要。一発完動しなくても、8割の土台と課題の可視化が得られれば開発としては大勝利。

# AGENTS.md

# プロジェクト概要

本プロジェクトは、Microsoft Accessを使用して、運送業システムのカスタマイズ履歴を管理するためのデータベースを新規作成するプロジェクトである。

作成対象のAccessファイル名は、次を想定する。

```text
運送業システムカスタマイズ管理.accdb
```

Accessオブジェクトはテキスト形式で管理し、別途用意された復元処理を使用してAccessデータベースへ反映する。

AIエージェントは、`Source`配下のテキストファイルを作成および編集する。

`.accdb`ファイル自体を直接編集してはならない。

---

# 本プロジェクトの目的

運送業システムの顧客別カスタマイズについて、次の情報を記録する。

- 顧客からの要望
- 対象となるAccessデータベース
- カスタマイズ作業の開始日時
- カスタマイズ作業の終了日時
- 作業状態
- 作業フォルダ
- カスタマイズ前のAccessオブジェクト一覧
- カスタマイズ後のAccessオブジェクト一覧
- 変更された可能性のあるAccessオブジェクト

本ツールの目的は、Accessオブジェクトの完全なソース差分管理ではない。

カスタマイズ作業を開始した結果として、顧客要望と変更対象候補の記録が自動的に残ることを重視する。

保存操作などにより、実際には変更していないAccessオブジェクトの更新日時が変わり、変更候補として含まれることは許容する。

---

# 開発方針

本プロジェクトは、既存Accessデータベースの変更ではなく、新規作成を前提とする。

要件書を基に、次のAccessオブジェクトを一から作成する。

- テーブル
- クエリー
- 標準モジュール
- フォーム
- フォームモジュール
- レポート
- レポートモジュール

必要なAccessオブジェクトが存在しない場合は、新しい定義ファイルを作成すること。

ただし、要件書に存在しない業務機能を独自判断で追加してはならない。

---

# 文字コード

`Source`配下のテキストファイルは、すべてUTF-8とする。

既存ファイルを編集する場合も、文字コードを変更しないこと。

CSV出力機能で作成するAccessオブジェクト一覧ファイルは、次の文字コードとする。

```text
UTF-8 BOMなし
```

---

# ディレクトリ構造

`Source`配下の基本構成は次のとおりとする。

```text
Source/
├─ AGENTS.md
├─ Forms/
├─ Modules/
├─ Queries/
├─ Reports/
├─ Samples/
│  ├─ Forms/
│  ├─ Modules/
│  ├─ Queries/
│  ├─ Reports/
│  └─ Tables/
└─ Tables/
```

ディレクトリ名を変更してはならない。

特に、クエリーフォルダ名は次とする。

```text
Queries
```

次の名称へ変更してはならない。

```text
Querys
```

独自判断で新しいディレクトリを追加してはならない。

---

# Source構造

## Tables/

Accessテーブル定義を格納する。

テーブルごとに、復元処理が読み取れる形式の定義ファイルを作成する。

テーブル定義には、必要に応じて次の情報を含める。

- テーブル名
- フィールド名
- データ型
- フィールドサイズ
- 必須
- 既定値
- 主キー
- インデックス
- 重複可否

テーブル構造は、要件書の内容を優先する。

---

## Queries/

AccessクエリーのSQLを格納する。

クエリーごとにSQL定義ファイルを作成する。

クエリーが参照するテーブル、クエリーおよびフィールドは、事前に定義されていなければならない。

存在しないオブジェクトやフィールドを参照してはならない。

Access SQLとして実行可能な構文を使用すること。

---

## Modules/

VBAコードを格納する。

対象は次のとおり。

- 標準モジュール
- フォームモジュール
- レポートモジュール

フォームモジュールのファイル名は、サンプルおよび既存の出力形式に従うこと。

一般的な形式は次のとおり。

```text
Form_フォーム名.cls
```

レポートモジュールの一般的な形式は次のとおり。

```text
Report_レポート名.cls
```

標準モジュールでは、原則として次を記述する。

```vb
Option Compare Database
Option Explicit
```

フォームモジュールおよびレポートモジュールでも、復元形式上問題がなければ同様に記述する。

---

## Forms/

フォーム定義を格納する。

フォームごとに、原則として次の2ファイルを作成する。

```text
フォーム名.txt
フォーム名_CT.txt
```

### フォーム名.txt

フォーム全体の定義を記述する。

ファイル名、CSVヘッダー、列順およびフィールド名は、`Samples/Forms/`に配置されたサンプルを使用すること。

### フォーム名_CT.txt

フォーム上のコントロール定義を記述する。

ファイル名、CSVヘッダー、列順、フィールド名およびコントロール種別の表記は、`Samples/Forms/`に配置されたサンプルを使用すること。

---

## Reports/

レポート定義を格納する。

レポートごとに、原則として次の2ファイルを作成する。

```text
レポート名.txt
レポート名_CT.txt
```

レポート定義のファイル名、CSVヘッダー、列順およびフィールド名は、`Samples/Reports/`に配置されたサンプルを使用すること。

レポートが参照するテーブルまたはクエリーは、事前に定義されていなければならない。

第一段階でレポートが必要ない場合は、要件にないレポートを作成してはならない。

---

# Samplesディレクトリ

`Samples/`には、現在の運送業システムから出力されたAccessオブジェクト定義の一部が配置されている。

サンプルは、AIエージェントへ次の内容を伝えるために使用する。

- ファイル命名規則
- ファイル構成
- CSVヘッダー
- CSV列順
- フィールド名
- 値の記述形式
- 空欄の表現
- Boolean値の表現
- 数値の表現
- Accessオブジェクト種別の表記
- コントロール種別の表記
- プロパティ値の表記
- VBAモジュールの保存形式

`Samples`配下の構成は次のとおりである。

```text
Samples/
├─ Forms/
├─ Modules/
├─ Queries/
├─ Reports/
└─ Tables/
```

新しいAccessオブジェクト定義を作成する前に、対応する`Samples`配下のファイルを確認すること。

---

# サンプルの優先順位

Accessオブジェクト定義の書式については、次の優先順位とする。

1. `Samples`配下にある同種オブジェクトの実例
2. 既に`Source`配下に存在する同種オブジェクト
3. 要件書
4. AGENTS.md
5. 一般的なAccessの知識

サンプルと一般的なAccessの知識が異なる場合は、復元処理との互換性を優先し、サンプルの形式を採用すること。

ただし、サンプルの業務内容や設計をそのまま流用してはならない。

---

# サンプルから使用してよい内容

サンプルから使用してよい内容は、原則として次のとおりである。

- ファイル命名形式
- ファイル拡張子
- CSVヘッダー
- CSV列順
- フィールド名
- プロパティ名
- 値の書式
- Boolean値の表現
- Nullまたは空欄の表現
- コントロール種別の表記
- セクションの表記
- イベントプロパティの表記
- 色の値を保存する形式
- 座標値を保存する形式
- フォント情報を保存する形式
- VBAファイルの保存形式
- クエリーSQLの保存形式
- テーブル定義の保存形式

---

# サンプルから流用してはならない内容

`Samples`配下には、現在の運送業システムで実際に使用しているデータや定義が含まれている。

次の内容は、今回の要件書に同じ指定がない限り流用してはならない。

- フォーム名
- レポート名
- テーブル名
- クエリー名
- モジュール名
- RecordSource
- ControlSource
- RowSource
- フィールド名
- コントロール名
- Caption
- 表示文字
- 顧客名
- 運転手名
- 得意先名
- 業務固有の名称
- 業務固有のSQL
- 業務固有のVBA処理
- イベント処理
- 計算式
- データ更新処理
- 削除処理
- フォルダパス
- ファイルパス
- 定数値
- 状態値
- 色
- フォント
- 座標
- 幅
- 高さ
- TabIndex
- フォーム全体のレイアウト

サンプルに存在する運送業システム固有のデータは、今回作成するカスタマイズ履歴管理ツールの仕様ではない。

AIエージェントは、サンプルの内容を新しいシステムへコピーするのではなく、保存形式を理解するためにのみ使用すること。

---

# サンプル内の実データの扱い

`Samples`配下には、実際の運送業システムで使用している名称や情報が含まれる可能性がある。

それらを次の目的で使用してはならない。

- 新しいテーブルの初期データ
- 新しいフォームの初期値
- テストデータ
- コメント内の具体例
- エラーメッセージ
- 作業報告
- 新規オブジェクト名
- 新規フィールド名
- 新規コントロール名

新しい定義内で例示値が必要な場合は、次のような一般的な仮名を使用すること。

```text
顧客A
作業A
サンプル
テスト
```

実際の運送業システムの顧客名やデータを、新しい定義へ転記してはならない。

---

# サンプルのレイアウト

サンプルに記録されている次の値は、今回の画面設計の指定ではない。

- Left
- Top
- Width
- Height
- BackColor
- ForeColor
- BorderColor
- FontName
- FontSize
- FontWeight
- TabIndex

これらの列名と値の保存形式は参考にしてよい。

ただし、具体的な値は今回の画面要件に合わせて新しく決定すること。

サンプルフォームのレイアウトをそのまま複製してはならない。

---

# CSVヘッダーの厳守

フォーム、レポートおよびテーブル定義などがCSV形式の場合は、対応するサンプルと同じヘッダーおよび列順を使用すること。

次は禁止する。

- ヘッダー名の変更
- 列順の変更
- 独自の列追加
- 必要な列の削除
- 類似する別名への変更
- 日本語名から英語名への変更
- 英語名から日本語名への変更
- 大文字と小文字の独自変更

使用しないプロパティがある場合も、列自体を削除してはならない。

サンプルと同じ方法で空欄を記述すること。

---

# サンプルに存在しない値

新しく作成するAccessオブジェクトで必要な設定が、サンプル内に存在しない場合は、次の順序で対応する。

1. 同じ種別の別サンプルを確認する
2. `Source`配下の既存ファイルを確認する
3. 要件書を確認する
4. Access標準のプロパティを使用できるか判断する
5. 復元処理が対応しているか確認する

復元処理が対応しているか判断できない場合は、推測で新しい列や表記を追加してはならない。

その場合は確認事項として報告すること。

---

# 作成順序

Accessオブジェクトは、原則として次の順序で作成する。

1. Tables
2. Queries
3. Modules
4. Forms
5. Reports

作成前に、各オブジェクトの依存関係を整理すること。

依存先が存在しない状態で、フォーム、レポートまたはクエリーを作成してはならない。

例：

```text
T_カスタマイズ作業
    ↓
Q_カスタマイズ作業一覧
    ↓
F_カスタマイズ作業一覧
```

---

# 新規作成時のルール

要件を実現するために必要なファイルが存在しない場合は、新規作成してよい。

ただし、次は禁止する。

- 同じ役割を持つファイルの重複作成
- 使用目的が不明な補助テーブルの追加
- 将来使用する可能性だけを理由とした機能追加
- 要件書にないマスタの追加
- 要件書にないフォームの追加
- 要件書にないレポートの追加
- 独自のディレクトリ追加
- 復元処理が対応していない形式の導入
- 第二段階の機能の先行実装
- サンプルにある既存オブジェクトの不要な複製

新規作成するAccessオブジェクトは、第一段階の完成に必要な範囲だけとする。

---

# AIによる設計裁量

本プロジェクトは、AIエージェントがMicrosoft Accessデータベースを一から構築できるかを確認する試験でもある。

要件書に明示されていない次の事項は、AIエージェントがAccessとして実用的かつ保守しやすい形を判断してよい。

- フォームの大きさ
- コントロールの配置
- 配色
- フォントサイズ
- ボタンの配置順
- 一覧フォームの列幅
- フォーム間の画面遷移
- 標準モジュールの分割
- 補助関数名
- ローカル変数名
- エラーメッセージの表現
- コメントの記述
- TabIndex
- Lockedの初期設定
- Enabledの初期設定
- Visibleの初期設定
- 作業中データを強調表示する方法
- 入力欄と表示専用欄を区別する方法
- 処理中の状態を利用者へ知らせる方法

ただし、次の事項は変更または創作してはならない。

- 要件書に記載された業務の流れ
- テーブルの目的
- 管理対象データ
- 必須入力項目
- 作業開始処理の内容
- 作業終了処理の内容
- ファイル名
- CSVの出力項目
- CSVの文字コード
- 状態値
- 作業フォルダの命名規則
- 第一段階と第二段階の区分
- 完成条件
- サンプルで示された復元用ファイルの書式

独自に決定した設計内容は、作業完了報告の「設計判断」欄へ記載すること。

---

# 要件書の画面イメージ

要件書に記載された画面イメージは、必要な入力項目と操作を示すための参考である。

次の内容を厳密に指定するものではない。

- コントロール位置
- フォームサイズ
- ボタン位置
- コントロール幅
- 色
- フォント
- 画面分割方法

AIエージェントは、利用者の操作の流れを考慮して、より使いやすい配置へ変更してよい。

必要な項目および処理を削除してはならない。

---

# 命名方針

命名規則が要件書に記載されている場合は、その名称を優先する。

要件書で名称が案として示されている場合は、特別な問題がない限り、その名称を採用する。

主な命名例は次のとおり。

```text
T_       本体データテーブル
TM_      設定・マスタテーブル
W_       作業用テーブル
Q_       クエリー
F_       フォーム
mod      標準モジュール
```

フォームモジュールは、サンプルの命名形式に従う。

一般的な形式は次のとおり。

```text
Form_フォーム名
```

レポートモジュールの一般的な形式は次のとおり。

```text
Report_レポート名
```

日本語のオブジェクト名およびフィールド名を使用してよい。

同じ意味の日本語名と英語名を、不必要に混在させないこと。

定数、関数、変数については、Access VBAとして読みやすい英語名を使用してよい。

---

# 作成対象テーブル

第一段階では、少なくとも次のテーブルを作成する。

## TM_カスタマイズ管理設定

履歴出力先などを管理する。

初期版で必要な主な項目は次のとおり。

- ID
- 履歴出力先
- 最終対象データベース
- 最終顧客名
- 更新日時

要件書で将来用とされている項目は、第一段階で必要性が低い場合は省略してよい。

省略した項目は作業報告へ記載すること。

---

## T_カスタマイズ作業

カスタマイズ作業履歴を管理する。

主な項目は次のとおり。

- 作業ID
- 顧客名
- 作業名
- 対象データベース
- 顧客要望メモ
- 開始日時
- 終了日時
- 作業フォルダ
- 状態

作業IDはオートナンバー型の主キーとする。

対象データベース、顧客要望メモおよび作業フォルダは、十分な文字数を保存できる型とする。

状態は文字列として管理する。

状態値は定数化する。

```vb
Public Const CUSTOMIZE_STATUS_WORKING As String = "作業中"
Public Const CUSTOMIZE_STATUS_COMPLETED As String = "完了"
Public Const CUSTOMIZE_STATUS_CANCELLED As String = "取消"
```

必要に応じて、開始失敗を表す状態を追加する場合は、要件との整合性を確認した上で作業報告へ記載すること。

---

## W_AccessObjectList

対象Accessデータベースから取得したオブジェクト一覧を一時的に保存する。

主な項目は次のとおり。

- ID
- オブジェクト種類
- オブジェクト名
- 作成日時
- 更新日時
- 並び順

IDはオートナンバー型の主キーとする。

オブジェクト一覧を取得するたびに全件削除して使用する。

複数利用者による同時実行への対応は、第一段階では必須としない。

---

# 作成対象クエリー

第一段階では、少なくとも次のクエリーを作成する。

## Q_ExportAccessObjectList

`W_AccessObjectList`の内容をCSV出力用に並べる。

出力項目は次のとおり。

```text
オブジェクト種類
オブジェクト名
作成日時
更新日時
```

並び順は次のとおり。

```text
並び順
オブジェクト名
```

SQLの基本形は次を参考とする。

```sql
SELECT
    オブジェクト種類,
    オブジェクト名,
    作成日時,
    更新日時
FROM
    W_AccessObjectList
ORDER BY
    並び順,
    オブジェクト名;
```

CSVの列名は次の英語名とする。

```text
ObjectType,ObjectName,DateCreated,DateModified
```

クエリーの日本語フィールド名を、CSV出力処理で英語ヘッダーへ変換してよい。

---

## 作業一覧用クエリー

作業一覧フォームで使用するクエリーを作成してよい。

一覧では、少なくとも次を表示できること。

- 状態
- 作業ID
- 顧客名
- 作業名
- 開始日時
- 終了日時
- 対象データベース
- 作業フォルダ

作業中の案件を選択するためのクエリーを、別途作成してよい。

---

# Accessフォーム方針

## 基本方針

本ツールは運送業システム本体ではなく、カスタマイズ履歴を管理するための独立したAccessツールである。

既存の運送業システムの配色、Fキー配置、紙の配車表を意識した一覧入力文化を継承する必要はない。

AIエージェントは、Accessの標準的な操作性を基に、実用的で分かりやすい画面を設計すること。

過度な装飾は避けること。

---

## メインフォーム

メインフォーム名は、原則として次とする。

```text
F_カスタマイズ作業管理
```

メインフォームでは、少なくとも次の入力ができること。

- 顧客名
- 作業名
- 対象データベース
- 顧客要望メモ

少なくとも次の操作ができること。

- 対象データベースの参照
- カスタマイズ開始
- カスタマイズ終了
- 作業一覧表示
- 作業フォルダを開く

開始処理と終了処理を同一フォームから実行するか、別フォームへ分けるかはAIエージェントが決定してよい。

ただし、利用者が現在どの作業を終了しようとしているかを明確に確認できるようにすること。

---

## 作業一覧フォーム

作業一覧では、少なくとも次の内容を確認できること。

- 状態
- 作業ID
- 顧客名
- 作業名
- 開始日時
- 終了日時
- 対象データベース

作業中の案件を識別しやすくすること。

終了対象となる作業を、作業IDにより選択できること。

一覧の並び順、列幅、配色および選択方法は、要件を満たす範囲でAIエージェントが決定してよい。

作業中の案件を上部に表示する、または作業中だけを絞り込めるようにしてよい。

---

## 設定画面

履歴出力先の設定が必要である。

設定方法は次のいずれでもよい。

- 独立した設定フォーム
- メインフォーム内の設定領域
- 初回起動時に設定を要求する処理

設定済みの履歴出力先を確認および変更できること。

履歴出力先が未設定の場合は、カスタマイズ開始処理を実行してはならない。

---

## 色と外観

特定の色体系は指定しない。

次の条件を満たす範囲で、AIエージェントが配色を決定してよい。

- 文字が読みやすい
- 入力欄と表示専用欄を判別できる
- 作業中と完了を判別しやすい
- 危険な操作と通常操作を区別できる
- Access標準環境で不自然に見えない

独自のデザインテーマや複雑な装飾は不要である。

---

## キーボード操作

Fキーの割り当ては必須としない。

Tabキーによって、自然な順番で入力項目とボタンを移動できるようにすること。

顧客名、作業名、対象データベース、顧客要望メモの順に入力できることを基本とする。

必要と判断した場合は、AIエージェントがアクセスキーやショートカットキーを設定してよい。

---

# 必須入力項目

カスタマイズ開始時には、次を必須とする。

- 顧客名
- 作業名
- 対象データベース
- 顧客要望メモ

顧客要望メモは、記録漏れ防止のため必須とする。

空欄の場合は、開始処理を実行してはならない。

入力エラー時は、問題のある項目を利用者へ明確に知らせること。

可能であれば、問題のあるコントロールへフォーカスを移動すること。

---

# 管理対象Accessファイル

対象となるAccessファイルは次のとおり。

```text
*.accdb
*.mdb
```

ファイル選択ダイアログでは、原則として上記の拡張子だけを選択対象とする。

対象ファイルの存在を確認すること。

可能であれば、対象ファイルを`Access.Application`で開けることを事前に確認すること。

---

# 管理対象オブジェクト

主な管理対象オブジェクトは次のとおり。

- テーブル
- クエリー
- フォーム
- レポート
- マクロ
- 標準モジュール
- クラスモジュール

原則として次を除外する。

- システムオブジェクト
- 隠しオブジェクト
- 一時オブジェクト
- `MSys`から始まるテーブル
- その他、管理上不要な内部オブジェクト

リンクテーブルは、第一段階では一覧へ含めてよい。

クラスモジュールを標準モジュールと明確に分離して取得できない場合は、取得方法と制約を作業報告へ記載すること。

---

# オブジェクト種類の並び順

オブジェクト一覧の並び順は、原則として次とする。

```text
1. Table
2. Query
3. Form
4. Report
5. Macro
6. Module
7. ClassModule
```

取得方法の制約により`Module`と`ClassModule`を分離できない場合は、無理に推測して分類しないこと。

その場合は`Module`として出力し、制約を作業報告へ記載してよい。

---

# オブジェクト一覧取得方法

別のAccessデータベースを、`Access.Application`で開く。

基本形は次のとおり。

```vb
Dim targetApp As Access.Application

Set targetApp = New Access.Application
targetApp.OpenCurrentDatabase targetDatabasePath
```

取得候補は次のとおり。

```vb
targetApp.CurrentData.AllTables
targetApp.CurrentData.AllQueries
targetApp.CurrentProject.AllForms
targetApp.CurrentProject.AllReports
targetApp.CurrentProject.AllMacros
targetApp.CurrentProject.AllModules
```

各`AccessObject`から、原則として次を取得する。

```vb
obj.Name
obj.DateCreated
obj.DateModified
```

取得した内容は、直接CSVへ書き出さない。

いったん`W_AccessObjectList`へ登録し、出力用クエリーで並べ替えてからCSVへ出力する。

処理終了時には、対象Accessを確実に閉じること。

```vb
targetApp.CloseCurrentDatabase
targetApp.Quit
Set targetApp = Nothing
```

エラー発生時も、必ず終了処理を通すこと。

`Access.Application`のプロセスを残してはならない。

---

# 出力フォルダ

履歴のルートフォルダは、`TM_カスタマイズ管理設定`で管理する。

ルートフォルダの下に顧客別フォルダを作成し、その下に作業別フォルダを作成する。

例：

```text
運送業システム_カスタマイズ履歴
├─ A社
│  ├─ 20260806_請求書変更
│  ├─ 20260810_運賃確認表追加
│  └─ 20260818_Excel取込修正
├─ B社
│  └─ 20260812_請求書変更
└─ C社
   └─ 20260820_配車入力項目追加
```

作業フォルダ名の基本形式は次のとおり。

```text
yyyyMMdd_作業名
```

日付は、カスタマイズ終了日ではなく、カスタマイズ開始日とする。

開始時に作成した作業フォルダのフルパスを、`T_カスタマイズ作業`へ保存する。

終了時は、保存されている作業フォルダを使用する。

終了日時からフォルダ名を再計算してはならない。

---

# 同一日の作業フォルダ

同じ顧客について、同じ日に複数のカスタマイズを開始することがある。

作業名が異なる場合は、別フォルダとする。

```text
A社
├─ 20260806_請求書変更
└─ 20260806_運賃確認表変更
```

同じ日に同じ作業名のフォルダが存在する場合は、連番を付ける。

```text
A社
├─ 20260806_請求書変更
└─ 20260806_請求書変更_02
```

さらに重複する場合は、次のように連番を増やす。

```text
20260806_請求書変更_03
20260806_請求書変更_04
```

連番は2桁を基本とする。

---

# フォルダ名の無効文字

顧客名および作業名に、Windowsのフォルダ名として使用できない文字が含まれる場合は置換する。

対象文字は次のとおり。

```text
\ / : * ? " < > |
```

置換文字は、アンダースコアを基本とする。

```text
_
```

フォルダ名の末尾にピリオドまたは空白が残らないようにすること。

顧客名または作業名が無効文字だけで構成され、実質的に空文字になる場合はエラーとする。

---

# 作成ファイル

各作業フォルダに、次の4ファイルを作成する。

```text
ObjectList_Before.csv
ObjectList_After.csv
ObjectList.csv
作業情報.txt
```

ファイル名は定数化する。

```vb
Public Const OBJECT_LIST_BEFORE_FILE As String = _
    "ObjectList_Before.csv"

Public Const OBJECT_LIST_AFTER_FILE As String = _
    "ObjectList_After.csv"

Public Const OBJECT_LIST_CURRENT_FILE As String = _
    "ObjectList.csv"

Public Const WORK_INFO_FILE As String = _
    "作業情報.txt"
```

---

# ObjectList_Before.csv

カスタマイズ開始時点のAccessオブジェクト一覧を保存する。

- 開始処理時に作成する
- 終了処理では変更しない
- カスタマイズ前の状態を保存する
- `ObjectList_After.csv`との比較に使用できる

---

# ObjectList_After.csv

カスタマイズ終了時点のAccessオブジェクト一覧を保存する。

- 終了処理時に作成する
- カスタマイズ後の確定記録として保存する
- 内容は終了処理後の`ObjectList.csv`と同じとする

終了処理が失敗した場合は、不完全なファイルを確定結果として扱わないこと。

---

# ObjectList.csv

Gitによる差分確認用ファイルとする。

開始処理時は、`ObjectList_Before.csv`と同じ内容を保存する。

終了処理時は、`ObjectList_After.csv`と同じ内容で上書きする。

開始時と終了時で同じファイルを更新することで、Git差分から変更された可能性のあるAccessオブジェクトを確認できるようにする。

---

# CSV出力形式

CSVのヘッダーは次のとおり。

```csv
ObjectType,ObjectName,DateCreated,DateModified
```

日付時刻の出力形式は次のとおり。

```text
yyyy/mm/dd hh:nn:ss
```

CSV値に次が含まれる可能性を考慮すること。

- カンマ
- ダブルクォーテーション
- 改行

CSV用のエスケープ処理は共通関数化する。

ダブルクォーテーションを含む値は、CSV仕様に従って二重化する。

---

# UTF-8 BOMなし出力

Access標準の`TransferText`だけに依存しない。

UTF-8 BOMなしで確実に出力できる方法を採用する。

候補は次のとおり。

- ADODB.Stream
- FileSystemObject
- VBA標準のOpen文
- Windows API

実装方法はAIエージェントが決定してよい。

ただし、実際にUTF-8 BOMなしとなる根拠を、コードコメントまたは作業報告へ記載すること。

外部ライブラリの追加インストールを前提としてはならない。

---

# 作業情報.txt

作業の基本情報および顧客からのカスタマイズ要望を保存する。

開始時は、原則として次の形式とする。

```text
作業ID=125
顧客名=A社
作業名=請求書変更
対象データベース=D:\顧客\A社\運送業システム.accdb
作業フォルダ=D:\運送業システム_カスタマイズ履歴\A社\20260806_請求書変更
開始日時=2026/08/06 14:45:00
終了日時=
状態=作業中

【顧客要望】
請求書に車両番号を表示したい。
摘要欄を少し狭くして、右側に車両番号欄を追加する。
```

終了時は、終了日時と状態を更新する。

作業情報.txtは、開始時と終了時に同じファイルを更新する。

実装メモは第二段階の機能であり、第一段階では必須としない。

---

# カスタマイズ開始処理

開始ボタンを押した時点で、作業レコードを1件作成する。

発番された作業IDを、そのカスタマイズ作業の管理番号とする。

処理順序は次を基本とする。

1. 入力内容を検証する
2. 履歴出力先の設定を確認する
3. 対象ACCDBの存在を確認する
4. 対象ACCDBを開けることを確認する
5. 作業中の案件が存在するか確認する
6. 必要に応じて警告を表示する
7. `T_カスタマイズ作業`へ新規登録する
8. 作業IDを取得する
9. 顧客フォルダを作成する
10. 作業フォルダを作成する
11. 作業フォルダのフルパスを作業レコードへ保存する
12. `W_AccessObjectList`を初期化する
13. 対象ACCDBの全オブジェクト一覧を取得する
14. `W_AccessObjectList`へ登録する
15. `ObjectList_Before.csv`を出力する
16. 同じ内容で`ObjectList.csv`を出力する
17. `作業情報.txt`を出力する
18. 作業状態を作業中として確定する
19. 開始完了メッセージを表示する

Git操作は第一段階では実行しない。

処理途中で失敗した場合は、正常な開始として扱ってはならない。

---

# カスタマイズ終了処理

終了処理では、顧客名、日付または作業名から対象フォルダを推測してはならない。

状態が作業中のレコード一覧から、終了する作業IDを選択する。

選択した作業IDのレコードから、次の情報を取得する。

- 顧客名
- 作業名
- 対象データベース
- 顧客要望メモ
- 開始日時
- 作業フォルダ

終了時に、対象データベースまたは作業フォルダを再入力させない。

処理順序は次を基本とする。

1. 状態が作業中の作業一覧を表示する
2. 終了対象の作業IDを選択する
3. 選択した作業IDの作業情報を取得する
4. 対象ACCDBの存在を確認する
5. 作業フォルダの存在を確認する
6. `W_AccessObjectList`を初期化する
7. 対象ACCDBの全オブジェクト一覧を再取得する
8. `W_AccessObjectList`へ登録する
9. `ObjectList_After.csv`を出力する
10. 同じ内容で`ObjectList.csv`を上書きする
11. `T_カスタマイズ作業`の終了日時を更新する
12. 状態を完了へ更新する
13. `作業情報.txt`を完了内容で再出力する
14. 完了メッセージを表示する

Git操作は第一段階では実行しない。

終了日が開始日と異なる場合でも、新しいフォルダを作成してはならない。

開始時に保存した作業フォルダを使用する。

---

# VBA構成方針

VBAは、機能別に標準モジュールへ分けてよい。

モジュール構成はAIエージェントが決定してよい。

例：

```text
modCustomizationWork
modAccessObjectList
modCsvExport
modFolderUtility
modFileUtility
modConstants
```

ただし、小規模な処理を過度に多数のモジュールへ分割してはならない。

一つの巨大なモジュールへすべてを詰め込むことも避ける。

機能の責任範囲が分かる構成とすること。

---

# VBAスタイル

新規VBAコードでは、読みやすく単純な構造を優先する。

過度なクラス化、抽象化または汎用化を行わない。

Access VBAとして自然な実装を優先する。

変数は、可能な限り具体的な型で宣言する。

原則として、Variantの多用を避ける。

DAOを使用する場合は、`DAO.Database`、`DAO.Recordset`などを明示する。

長いSQL文を一行へ詰め込まない。

広範囲に`On Error Resume Next`を使用して、エラーを無視してはならない。

---

# エラー処理

主要なPublic処理および外部資源を扱う処理には、エラー処理を実装する。

考慮する主な状態は次のとおり。

- 対象ACCDBが存在しない
- 対象ACCDBを開けない
- ACCDBが排他利用中
- 出力先フォルダを作成できない
- ワークテーブルへの登録に失敗する
- CSVを書き込めない
- 作業情報ファイルを書き込めない
- 終了対象となる作業中データがない
- 対象ACCDBが開始時から移動または削除されている
- 作業フォルダが移動または削除されている
- `Access.Application`の終了に失敗する
- ファイル選択ダイアログがキャンセルされる
- 設定テーブルにデータがない
- 履歴出力先が未設定である

終了処理や解放処理など、限定的に`On Error Resume Next`が必要な場合は、使用範囲を最小限にすること。

---

# 整合性確認

ファイルを作成または変更した後は、次を確認すること。

## テーブル

- フィールド名が重複していない
- 主キーが適切に定義されている
- データ型が用途に合っている
- 必須フィールドとNull許可が矛盾していない
- インデックスの重複可否が明確である
- 長いファイルパスを保存できる
- 顧客要望メモを十分に保存できる
- `Samples/Tables/`と同じ定義形式になっている

## クエリー

- 参照テーブルが存在する
- 参照フィールドが存在する
- Access SQLとして成立する
- 予約語を使用する場合は角括弧で囲んでいる
- 並び順が安定している
- `Samples/Queries/`と同じ保存形式になっている

## フォーム

- RecordSourceが存在する
- ControlSourceが存在する
- RowSourceが存在する
- イベントプロシージャ名がモジュールと一致する
- コントロール名が重複していない
- TabIndexが不自然になっていない
- 必須入力項目が入力できる
- 表示専用項目を誤って編集できない
- 作業IDを誤認しない
- 作業中と完了を識別できる
- `Samples/Forms/`と同じCSVヘッダーおよび列順になっている

## レポート

- RecordSourceが存在する
- ControlSourceが存在する
- コントロール名が重複していない
- `Samples/Reports/`と同じCSVヘッダーおよび列順になっている

## モジュール

- 呼び出している関数が存在する
- フォーム名、クエリー名およびテーブル名が定義と一致する
- DAOとAccessオブジェクトの型が適切である
- エラー処理で本来のエラーを隠していない
- `Access.Application`を解放している
- ファイルハンドルを閉じている
- CSVエスケープ処理が共通化されている
- UTF-8 BOMなしで出力できる
- `Samples/Modules/`と同じ保存形式になっている

---

# 不明点の扱い

## 確認が必要な項目

次の項目は推測で実装してはならない。

- 要件書内で矛盾する業務仕様
- データの削除条件
- 履歴データを物理削除するかどうか
- 状態値の追加が業務上の意味を変える場合
- 第一段階と第二段階の境界
- CSVの出力項目変更
- 作業フォルダ命名規則の変更
- 必須入力項目の変更
- 管理対象Accessオブジェクトの追加または除外
- 復元用テキスト形式が不明な場合
- サンプル同士の形式が矛盾している場合
- サンプルに必要なプロパティが存在しない場合
- UTF-8 BOMなし出力が実行環境上成立しない場合

該当部分の実装を停止し、確認を求めること。

該当部分と無関係な作業は継続してよい。

---

## AIが判断してよい項目

次の項目は、要件に反しない範囲でAIエージェントが決定してよい。

- フォームの大きさ
- コントロールの位置
- コントロールの幅と高さ
- ラベル文言の細かな表現
- フォントサイズ
- 配色
- セクション内の余白
- ボタンの配置
- フォーム間の画面遷移
- 一覧の列幅
- 一覧の並び順
- 作業中の強調方法
- 補助関数名
- ローカル変数名
- エラーメッセージの細かな文言
- コメントの表現
- TabIndex
- モジュールの分割
- 開始失敗時の内部処理方法
- 処理中表示の方法

ただし、ファイル形式、CSVヘッダー、列順およびフィールド名はAIが変更してよい項目には含まれない。

---

# 第一段階の実装範囲

第一段階では、次の機能まで実装する。

- 管理用Accessファイルの構成
- 設定テーブル
- カスタマイズ作業テーブル
- オブジェクト一覧ワークテーブル
- 出力用クエリー
- 開始処理を実行するフォーム
- 終了処理を実行するフォームまたは機能
- 対象ACCDBの選択
- 顧客名の入力
- 作業名の入力
- 顧客要望メモの入力
- 作業IDの発番
- 顧客別フォルダ作成
- 作業別フォルダ作成
- 対象ACCDBの全オブジェクト一覧取得
- ワークテーブルへの登録
- UTF-8 BOMなしCSV出力
- 4ファイルの作成
- 作業中状態の管理
- 完了状態の管理
- 作業IDによる終了対象選択
- 作業一覧表示
- 作業フォルダを開く機能
- 前回選択した対象データベースの保存

Git操作は手動で行う。

---

# 第二段階の機能

次の機能は第一段階では実装しない。

- Git addの自動実行
- Git commitの自動実行
- BeforeとAfterの自動比較
- 追加オブジェクト一覧
- 更新オブジェクト一覧
- 削除オブジェクト一覧
- 実装メモ入力
- 作業終了時の実装メモ追記
- 顧客名マスタ
- 高度な過去作業検索
- 顧客別カスタマイズ一覧
- 対象Accessオブジェクトを直接開く機能
- ObjectList.csvから対象定義を個別出力する機能
- Gitコミット結果の記録

将来用フィールドをテーブルへ用意するかどうかは、第一段階の単純さを優先して決定すること。

---

# 完成条件

次の流れを問題なく実行できる構成になっていれば、第一段階の完成とする。

1. 顧客名を入力できる
2. 作業名を入力できる
3. 対象ACCDBを選択できる
4. 顧客要望を入力できる
5. カスタマイズ開始を実行できる
6. 作業IDが発番される
7. 作業レコードが作業中として登録される
8. 顧客フォルダが作成される
9. 作業フォルダが作成される
10. ObjectList_Before.csvが作成される
11. ObjectList.csvが作成される
12. 作業情報.txtが作成される
13. 対象ACCDBを実際にカスタマイズできる
14. 作業中一覧から作業IDを選択できる
15. カスタマイズ終了を実行できる
16. 開始時に保存された対象ACCDBが使用される
17. 開始時に保存された作業フォルダが使用される
18. ObjectList_After.csvが作成される
19. ObjectList.csvが終了時内容で上書きされる
20. 作業情報.txtが完了内容で更新される
21. 作業レコードが完了になる
22. ObjectList_Before.csvとObjectList_After.csvを比較できる
23. ObjectList.csvをGit差分で確認できる
24. 作業一覧に顧客名、作業名、状態、開始日時および終了日時が表示される
25. 作業フォルダを開ける
26. 作成された全定義ファイルが、対応するSamplesと同じ形式になっている

Accessへ復元して実際に動作させていない段階では、完成または動作確認済みと報告してはならない。

---

# 作業報告

作業終了時は、次の形式で報告すること。

```text
【参照したサンプル】

Forms/
- ○○

Modules/
- ○○

Queries/
- ○○

Reports/
- ○○

Tables/
- ○○

【作成したファイル】

Tables/
- ○○

Queries/
- ○○

Modules/
- ○○

Forms/
- ○○

Reports/
- ○○

【作成したAccessオブジェクト】

テーブル：
- ○○

クエリー：
- ○○

標準モジュール：
- ○○

フォーム：
- ○○

レポート：
- ○○

【主な依存関係】

- ○○ → ○○ → ○○

【設計判断】

- フォーム構成：
- 画面遷移：
- 配色：
- モジュール分割：
- 開始失敗時の扱い：
- UTF-8 BOMなし出力方法：
- その他：

【サンプルから参照した形式】

- CSVヘッダー：
- 列順：
- コントロール種別：
- 空欄の表現：
- Boolean値の表現：
- その他：

【要件書から省略した項目】

- ○○

【仮設定した内容】

- ○○

【確認が必要な内容】

- ○○

【未実装】

- ○○

【復元後に確認する項目】

- テーブル作成
- クエリー実行
- フォーム表示
- 必須入力チェック
- ファイル選択
- 作業ID発番
- 作業フォルダ作成
- オブジェクト一覧取得
- CSV文字コード
- CSV内容
- 作業情報.txt
- 開始処理
- 終了処理
- 作業一覧
- 作業フォルダを開く処理
- エラー時のAccess.Application終了
```

作成していないものを作成済みと報告してはならない。

Access上での動作を実際に確認していない場合は、動作確認済みと報告してはならない。

---

# 禁止事項

次を独自判断で行ってはならない。

- ディレクトリ名の変更
- `Queries`を`Querys`へ変更すること
- ファイル形式の変更
- CSVヘッダーの変更
- CSV列順の変更
- 復元処理の仕様変更
- `.accdb`ファイルの直接編集
- 要件書にない業務機能の追加
- 必須入力項目の削除
- 状態値の意味変更
- 作業ID以外による終了対象の推測
- 開始日以外の日付による作業フォルダ名の決定
- 終了時の新規作業フォルダ作成
- `ObjectList_Before.csv`の終了時上書き
- 第二段階機能の先行実装
- Gitコマンドの自動実行
- 同じ機能を持つ複数フォームの重複作成
- 大規模なフレームワークの導入
- 過度なクラス設計
- 外部ライブラリの追加を前提とした実装
- エラーを隠すための広範囲な`On Error Resume Next`
- `Access.Application`プロセスを残す実装
- Samples内の業務データを新しいシステムへ転記すること
- Samples内の顧客名や業務固有名称をテストデータとして使用すること
- Samples内のレイアウトをそのまま複製すること
- Samples内のVBA処理を要件確認なしに流用すること

---

# 基本姿勢

AIエージェントは、要件書を基にAccessデータベースの土台を新規作成する。

本プロジェクトでは、画面配置、配色、フォーム構成およびモジュール構成について、AIエージェントに一定の設計裁量を与える。

ただし、業務仕様、保存内容、処理順序、完成条件および復元用ファイル形式を独自に変更してはならない。

`Samples`配下のファイルは、現在の運送業システムから出力された実例である。

サンプルから学ぶのは次の内容である。

- どのようなファイル名で保存するか
- どのようなCSVヘッダーを使用するか
- どのような列順で保存するか
- 各値をどのような形式で記述するか
- 復元処理がどのような定義を受け付けるか

サンプルから学んではならないのは次の内容である。

- 何という業務オブジェクトを作るか
- どのような画面配置にするか
- どのような業務処理を実装するか
- どのデータを初期値として使用するか

Accessの標準的な操作性を保ちながら、単純で、見やすく、保守しやすい構成を優先すること。

作成したテキスト定義は、Accessへ復元して初めて動作確認できる。

そのため、次を重視する。

- Samplesとのファイル形式の一致
- テキスト定義間の整合性
- Accessオブジェクト間の依存関係
- 復元可能な形式
- エラー時の後始末
- 未確認事項の明示
- AIが独自に判断した設計内容の報告

本ツールは自分用の業務支援ツールである。

見た目を既存の運送業システムへ合わせることよりも、AIエージェントがAccessとしてどのような設計を行うかを確認することを重視する。

指示書（プロンプト）は覚えるな！考えるな！書いてもらいなさい

■ 1. 「プロンプトを学ぶ」という本末転倒

■ 2. 現場の「めんどくさい」から始まった実験

■ 3. チーム編成：人間・参謀・職人の3層構造

■ 4. ChatGPTが吐き出した「AGENTS.md」の実物

■ 5. 運命の21分16秒と、Claudeの「神設計」

■ 6. 「動かなかった」だが大成功である

■ 7. プロンプトは覚えるな、AIと遊べ

🤖 Geminiによる副音声解説

📝 本日のAIコーディングログ

0 件のコメント :

コメントを投稿

カテゴリー

最近の投稿

人気記事

ブログアーカイブ

指示書（プロンプト）は覚えるな！考えるな！書いてもらいなさい

■ 1. 「プロンプトを学ぶ」という本末転倒

■ 2. 現場の「めんどくさい」から始まった実験

■ 3. チーム編成：人間・参謀・職人の3層構造

■ 4. ChatGPTが吐き出した「AGENTS.md」の実物

■ 5. 運命の21分16秒と、Claudeの「神設計」

■ 6. 「動かなかった」だが大成功である

■ 7. プロンプトは覚えるな、AIと遊べ

🤖 Geminiによる副音声解説

📝 本日のAIコーディングログ

この記事をシェアする

0 件のコメント :

コメントを投稿

カテゴリー

最近の投稿

人気記事

ブログアーカイブ