業務改善・プロジェクト推進・自動化活動の実績から、部署間の調整や組織全体への貢献と成長を伝える自己評価文の暫定案を作成するプロンプト。

添付する半期評価シートの自己評価欄を埋めたいです。以下は社外AIと整理した実績です。評価項目の詳細は添付ファイルを参照してください。
【実績① 業務改善】
自社と出向先で業務効率に差があると感じ、自社の業務手法やツールを紹介。前年から費用面を含めて導入を働きかけ、今期はツール提供と適用支援を実施。一部は実運用を開始した。
【実績② プロジェクト推進】
支援を受けながら新規PJのリーダーを担当。顧客・前工程・自部署の全体最適を考慮し、自部署の日程を調整。自部署の作業期間が圧迫される影響は、他業務の自動化による負荷軽減で対応した。
【実績③ 自動化活動の取りまとめ】
設計・実装業務の自動化を取りまとめ、メンバーへの作業割り振りや調整を実施。現場作業者が率直な意見を出せるよう、心理的なハードルを下げる接し方や傾聴を心がけた。
【依頼】
上記を基に、評価シートの各項目に対応した自己評価文を作成してください。
特に「自分の担当作業だけでなく、部署間の調整や組織全体の改善にも取り組むようになった」という成長を伝えたいです。
実績の誇張や未確認の数値は避け、不足している情報は必要に応じて一問ずつ質問してください。時間が限られているため、まず全項目の暫定案を提示してください。

文書一覧Excelと紐づけDBから使用プログラム一覧を生成する、実行時AI不要・連続実行対応の業務自動化ツールについて設計を相談するプロンプト。

Excel文書一覧から使用プログラム一覧を自動生成するツールの設計相談

あなたには、Pythonを中心とした業務自動化ツールの設計について、技術的な壁打ち相手になってほしいです。

現在、Excelで管理されている文書一覧と、別途管理されているプログラムの紐づけ情報を利用して、プロジェクトで使用するプログラムの一覧を自動生成するツールを検討しています。

ChatGPTとの事前検討で、ある程度の構想はまとまっています。以下に業務の背景、仕様、課題、現在のアイデアを整理します。

現時点では実装を開始せず、まずは業務の仕組みを正しく理解したうえで、より効率的で現実的な自動化方法を一緒に検討してください。

⸻

1. 最終的に実現したいこと

プロジェクトごとに存在する「文書一覧Excel」を入力し、そのプロジェクトで使用するプログラムの一覧をExcel形式で自動生成したいです。

その際、以下を自動化したいと考えています。

1. 入力Excelから有効な文書No.を抽出する
2. 文書No.とプログラムの紐づけ情報を取得する
3. 紐づけ条件に応じて使用するプログラムNo.を選定する
4. プロジェクト内の識別番号ごとに、使用するプログラムへ「○」を付ける
5. 最終的なプログラム一覧Excelを出力する

出力したExcelは別のツールの入力として利用する予定です。

そのため、将来的には複数のツールを連続実行することを想定しています。

2. 入力となる文書一覧Excel

プロジェクトごとに文書一覧のExcelファイルが存在します。

各文書には以下の情報があります。

* 文書名
* 文書No.
* 有効・無効を表す「○」

2-1. 有効文書の判定

文書一覧には、文書No.ごとに「○」を記載する列があります。

「○」が付いている場合、その文書は対応する識別番号に対して有効です。

「○」がなければ、その識別番号に対しては有効ではありません。

2-2. ○を記載する列が複数ある

1つのExcelファイル内に、「○」を記載する列が2列以上存在する場合があります。

それぞれの列の1行目には、固有の識別番号が記載されています。

さらに、1つのセルに複数の識別番号が改行区切りで記載されている場合もあります。

例えば、以下のような構造です。

文書No.	文書名	ID001 / ID002	ID003
D001	文書A	○	
D002	文書B		○
D003	文書C	○	○

※「ID001 / ID002」は、実際のExcelでは1つのセルに改行区切りで記載されています。

この場合、ID001とID002は別々の識別番号として扱います。

つまり、D001はID001とID002で有効、D003はID001・ID002・ID003のすべてで有効です。

3. 文書とプログラムの関係

各文書No.には、プログラムが紐づいています。

プログラムは以下の3要素で管理されています。

* プログラム名
* 番号1
* 番号2

便宜上、以下のように表現します。

ABC_100_003

これは「プログラム名=ABC、番号1=100、番号2=003」を表す仮の管理名です。実際のファイル名がこの形式であるとは限りません。

3-1. 紐づけパターン①：番号2が自由選択

文書No.に対し、プログラム名と番号1までが指定されています。

番号2は自由選択ですが、最新番号の使用が推奨されています。

今回のツールでは、原則として最新の番号2を自動選択したいです。

例：

* ABC_100_001
* ABC_100_002
* ABC_100_003

この3つが存在する場合、ABC_100_003を選択します。

なお、最新番号の判定方法や、選択可能な番号の情報源については、今後確認が必要です。

3-2. 紐づけパターン②-A：番号2まで固定指定

プログラム名、番号1、番号2がすべて指定されています。

この場合は指定されたプログラムをそのまま採用します。

例：

DBでABC_100_002が指定されていれば、最新版が別に存在していてもABC_100_002を採用します。

3-3. 紐づけパターン②-B：日本語の条件によって候補から1つ選択

ここが今回の自動化で最も難しい部分です。

1つの文書No.に対し、同じプログラム名で番号の異なる候補が複数紐づいている場合があります。

この場合、候補をすべて使用するのではなく、適切なプログラムを1つ選択する必要があります。

選択条件はDBに日本語の文章で記載されています。

条件の例：

* 使用する部品の型番によって選択する
* 特定の機能を使用するかどうかによって選択する
* 特定の仕様を採用しているかどうかによって選択する

これらの条件は複数種類存在し、内容によっては人間が判断するのも面倒です。

単純なif文によるルール化が容易ではないと感じています。

3-4. 重要：②-Bの条件はプロジェクト単位で決まる

②-Bの判断結果は、同じExcelファイル内の識別番号によって変わるものではありません。

条件はプロジェクト全体の属性によって決まります。

例えば、同じExcelファイルにID001、ID002、ID003が存在しても、特定の②-Bに対する選定結果は共通です。

別のプロジェクトのExcelファイルを処理した場合には、プロジェクトの属性が異なるため、選定結果が変わる可能性があります。

したがって、②-Bの選定を識別番号ごとに繰り返す必要はありません。

4. 期待する出力Excel

プログラムを行方向に一覧化し、識別番号を列方向に展開したいです。

例えば、次の形式です。

プログラム名	番号1	番号2	ID001	ID002	ID003
ABC	100	003	○	○	
DEF	200	002			○
GHI	300	005	○	○	○

重要な点は次のとおりです。

* 入力Excelの1つのセルに複数の識別番号があれば、出力では別々の列に展開する
* 文書No.に紐づくプログラムを選定してから、識別番号ごとに○を付与する
* 同じプログラム名・番号1・番号2の組み合わせは、原則1行に集約する
* 同じプログラムが複数の有効文書に紐づく場合、該当する識別番号の○を統合する
* ②-Bで選定されるプログラムNo.は、同一プロジェクト内では共通とする

出力Excelの詳細なレイアウトや後続ツールとのインターフェースは、今後検討したいです。

5. 現在存在するDBや関連ファイル

現時点で把握している情報源は、以下の3つです。

① プロジェクトごとの文書一覧Excel

どの文書No.が有効なのかを管理しています。

② 文書No.ごとの個別Excelファイル

文書No.ごとにExcelファイルが存在します。

文書とプログラムの紐づけ情報や、②-Bの日本語条件などを参照する情報源として考えています。

具体的なセル構造や記載形式は、これから確認する必要があります。

③ 文書管理チームが新しく作成した紐づけDB

文書を管理しているチームが、別途紐づけ情報をまとめたDBを作成したようです。

ただし、現時点ではそのDBの具体的な内容や構造は把握していません。

特に、以下を確認する必要があります。

* 文書No.とプログラムの紐づけが網羅されているか
* 番号1、番号2の情報が格納されているか
* ②-Bの日本語の選定条件が含まれているか
* 個別Excelとの情報の整合性が取れているか
* 今後どちらのデータを正として管理するか

この新DBをうまく使えば、個別Excelを大量に解析する必要がなくなる可能性があります。

6. ②-Bの判定に必要なプロジェクト情報

判断条件に使われる情報は、必ずしもExcelやDBから機械的に取得できるわけではありません。

例えば、使用する部品の型番や機能の採用有無などは、プロジェクトの担当者が知識として把握しています。

したがって、②-Bの完全自動化を行うためには、プロジェクト固有の情報を何らかの形でツールに与える必要があります。

ただし、判断条件は複雑で多岐にわたるため、すべての項目を最初から固定フォームとして設計できるかは不明です。

7. AI利用に関する重要な制約

完成したツールは、AIを使用せずに動作する必要があります。

理由は、ツールの利用者全員がAIを利用できる環境ではないためです。

AIは開発段階での設計支援、日本語条件の分析、ルール化、コード作成などに活用できます。

一方、完成したツールの実行時には、AIサービスへのアクセスやAIのライセンスを要求しない構成を希望します。

Pythonなどによる通常のプログラム処理で完結させたいです。

8. 連続実行に関する重要な制約

生成したプログラム一覧Excelは、別のツールに入力する予定です。

将来的には複数のツールを連続実行する構成を想定しています。

そのため、連続実行中にユーザーへ質問するような仕組みは避けたいです。

②-Bで人間の判断が必要な場合でも、連続実行前に回答や選定を完了できる仕組みが望ましいです。

例えば、次のような構成を考えています。

事前準備フェーズ

1. 文書一覧ExcelとDBを読み込む
2. ②-Bに該当するプログラム候補と日本語条件を抽出する
3. 必要なプロジェクト情報を整理する
4. ユーザーが質問に回答する
5. 自動判定できない条件はユーザーが候補を直接選択する
6. 回答内容や選定結果を設定ファイルなどに保存する

自動実行フェーズ

1. 文書一覧Excelを読み込む
2. DBと保存済みの設定を参照する
3. ①・②-A・②-Bのプログラムを選定する
4. 識別番号別の○を付与する
5. プログラム一覧Excelを出力する
6. 後続ツールに処理を引き継ぐ

自動実行中に必要な設定が不足していたり、DBの更新により選定結果を保証できなくなった場合は、勝手に推測して進めず、エラーとして検出したいです。

9. 現時点で考えている自動化案

これまでの検討では、以下の構成が有力だと考えています。

案A：事前設定ツールと一覧生成ツールを分離する

事前設定ツールは人間が操作し、②-Bの選定に必要な情報を保存します。

一覧生成ツールは保存済みの設定を参照して、完全無人で処理します。

これによって、既存の連続実行ツールとの連携を容易にしたいです。

案B：②-Bの条件を可能な範囲でルール化する

例えば、部品型番や機能の採用有無など、明確な条件はPythonで判定できるようにします。

日本語で書かれたDBの条件を、開発段階でAIを使って構造化することも検討しています。

ただし、AIが変換したルールについては、正確性を検証する必要があります。

案C：複雑な条件は事前に手動選択する

すべての②-Bをプログラムで判定しようとせず、難しい条件については、事前設定時に人間がプログラムNo.を直接選択できるようにします。

その結果を保存し、連続実行時には再利用します。

案D：共通の質問をまとめる

複数の②-Bの選定で同じプロジェクト情報を必要とする場合、1回の回答で複数の判定に使えるようにします。

例：

「使用する部品型番」を1回回答すれば、その情報を参照する複数の②-Bを判定できるようにする。

質問や手動選択の数をできるだけ減らすことが目標です。

10. 段階的な開発案

最初から②-Bを100%自動判定しようとすると、開発規模が大きくなりそうです。

そのため、次のような段階的開発を考えています。

第1段階：まず確実に動作するツールを作る

* 文書一覧Excelの解析
* 識別番号の展開
* ①と②-Aの自動選定
* ②-Bの事前手動選択
* プログラム一覧Excelの生成
* 連続実行対応

第2段階：②-Bの選定作業を効率化する

* 頻出する条件のルール化
* プロジェクト情報の事前回答
* 回答結果の保存と再利用
* 共通条件の統合

第3段階：ルール管理の高度化

* ②-Bの選定ルールの拡充
* DB更新時の影響検出
* ルールの再確認機能
* 設定や選定履歴の管理

ただし、この進め方が本当に最適かも含めて検討したいです。

11. 追加で設計すべき課題

現在、以下の点は未確定です。

* 新しい紐づけDBの構造と情報の網羅性
* 個別Excelの具体的なフォーマット
* 最新の番号2を判定する方法
* ②-Bの日本語条件の種類と複雑さ
* 事前回答をどのような形式で保存するか
* DBが更新された際に保存済みの選定結果をどう扱うか
* 複数の文書No.から同一プログラムが選定された場合の集約方法
* 一意に選定できない場合のエラー処理
* 出力Excelの詳細なレイアウト
* 後続ツールとの連携方法
* 実行環境や利用可能なPythonライブラリ

これらは、実際のデータを確認しながら決定したいです。

12. あなたにお願いしたいこと

ここから、設計の壁打ちを進めたいです。

特に以下を重視してください。

1. ②-Bの日本語条件を、実行時AIなしで効率的に扱う方法を考えること
2. 人間が判断・回答する回数を可能な限り減らすこと
3. 既存の連続実行ツールへ組み込みやすい構成にすること
4. DBの変更や条件の追加に強い仕組みを考えること
5. 実装の複雑さと、自動化で削減できる工数のバランスを考えること
6. 選定ミスが発生しないよう、判定根拠やエラー処理を設計すること

これまでの案が最適とは限りません。より良い方法があれば、積極的に提案してください。

まずは、ここまでの仕様に対するあなたの理解を整理し、設計上の問題点や改善案を示してください。

そのうえで、詳細設計に必要な情報を私に質問してください。

質問は一度に大量にせず、重要なものから順に確認してください。

なお、最初からコードを大量に生成する必要はありません。まずは実現方式を固めることを優先したいです。

修正済みソースDBから対象プロジェクトの対応ファイルを安全に照合・上書きし、CSVログを残すWindows向けPythonツールの開発依頼。

# 修正済みソース自動差し替えツール 開発依頼

## 1. 開発目的

複数のプロジェクトから共通参照される修正済みソースDBを利用し、指定プロジェクト内に対応する修正前ファイルが存在する場合、修正済みソースの内容で自動的に上書きするPythonツールを開発してください。

本ツールは将来的に、複数ツールを順番に実行する自動化システムの一部として使用します。

**重要：ファイル名の照合に必要な社内固有の命名規則は、まだ提示していません。実装前に必ず私へ質問してください。規則を勝手に推測して実装しないでください。**

## 2. 動作環境

- OS：Windows 11
- 開発言語：Python
- 開発環境：VS Code＋GitHub Copilot
- 実行形式：コマンドライン
- GUI：不要
- 開発中：Pythonスクリプトとして実行
- 開発完了後：exe化する予定

可能な限りPython標準ライブラリを使用してください。

## 3. ツールの入力

### 3.1 差し替え対象プロジェクト

実行時のコマンドライン引数で、プロジェクトフォルダのパスを1つ指定します。

実行例：
```
python replace_source.py "C:\Work\ProjectA"
```

指定フォルダ以下を再帰的に検索してください。

### 3.2 修正済みソースDB

DBの場所は、ツール本体と同じフォルダに配置する `config.ini` で指定します。

以下の2方式に対応してください。

**方式A：共有フォルダ**

- 設定された共有フォルダからファイルを取得
- 指定フォルダ以下を再帰的に検索

**方式B：SVN**

- 設定されたSVNリポジトリのURLから取得
- `svn export` を使用
- 常に最新リビジョン（HEAD）を使用
- Windowsの一時フォルダに展開
- 処理終了後に一時フォルダを削除
- 既存のSVN認証情報を利用
- ツールの設定ファイルにパスワードを保存しない

設定ファイルで `svn` または `folder` を明示的に指定する方式としてください。

取得に失敗した場合、ほかの方式への自動切り替えは行いません。

`svn.exe` が実行可能か確認し、利用できない場合はエラーとしてください。

## 4. 修正済みDBのフォルダ構造

修正済みDBは、プログラムNoごとのフォルダに分かれています。

各プログラムNoフォルダの下には、さらに複数階層のサブフォルダが存在する場合があります。

- すべてのサブフォルダを検索対象にする
- サブフォルダの位置による除外は行わない
- DB配下のすべてのファイルが修正済みソースである
- 同じプログラムNoと同じファイル名の組み合わせはDB内で一意
- 同じファイル名でも、プログラムNoが異なるファイルは存在する
- DB側にリネーム済みファイルは存在しない

対象ファイルは `.c`、`.h` に限定しません。すべてテキストエディタで読み取り可能な形式ですが、その他の拡張子も存在し得ます。

## 5. ファイルの対応付け条件

以下の条件をすべて満たす場合のみ、修正済みソースとプロジェクト側ファイルを対応付けてください。

### 条件1：プログラムNoの一致

- プログラムNoはファイルの1行目に記載されている
- 特定の番号部分を抽出する必要はない
- **1行目の文字列全体を完全一致で比較する**
- 1行目は英数字・半角記号のみ
- 末尾の改行コード（CRLF、LF）は比較から除外
- その他の文字、空白、大文字・小文字は厳密に比較する
- バイナリで1行目を読み取り、バイト列として比較してよい

### 条件2：ファイル名の対応

サーバー側はオリジナルのファイル名です。

プロジェクト側は、オリジナルのファイル名に特定の命名規則で任意の文字列が挿入されている場合があります。

ファイル名が完全一致するケースもあります。

例：

- サーバー：`ABC_XX.c`
- プロジェクト：`ABC_123_XX.c`
- プロジェクト：`ABC_456_XX.c`

ただし、これは単なる例示です。

**実際の命名規則では、元のファイル名にも挿入文字列にも `_` が含まれ得ます。**

挿入位置には機械的な規則性があります。

この具体的な規則は社内固有情報のため、実装前に必ず私に問い合わせてください。

単純な部分文字列検索や、任意の `_` を挿入位置と見なすアルゴリズムを勝手に採用しないでください。

照合ロジックは、設定ファイルではなくPythonのコード内に実装する方針です。

ファイル名の大文字・小文字は区別しません。

### 条件3：拡張子の一致

- 拡張子は一致必須
- 大文字・小文字は区別しない
- `.c` と `.h` のように拡張子が異なる場合は対応付けない

## 6. ヘッダーファイルの補足

プロジェクト側には、リネーム後のヘッダーファイルをインクルードするために、オリジナル名のヘッダーファイルが別途存在する場合があります。

このインクルード専用ファイルは、通常のプログラムNoとは異なる1行目を持っています。

そのため、プログラムNoの完全一致条件によって自然に除外されます。

インクルード専用ファイルを特別に識別する処理は不要です。

## 7. 差し替え処理

以下の順序で処理してください。

1. 設定ファイルを読み込む
2. 修正元DBを取得・検索する
3. プロジェクト側の全ファイルを再帰検索する
4. ファイル名・拡張子・プログラムNoを照合する
5. 差し替え対象の一覧を確定する
6. すべての照合が正常終了した場合のみ差し替えを開始する
7. 差し替え結果をCSVに記録する

### 差し替え方法

- 修正済みソースの内容を丸ごとコピー
- プロジェクト側のファイル名は維持
- フォルダ位置も維持
- ファイル内容の追加加工は不要
- 差分適用は行わない
- バックアップは作成しない
- 一時ファイルを介した置き換えも不要
- `shutil.copyfile()` などを使用して直接上書き
- 内容が同じかどうかの事前比較は不要
- 上書き後の更新日時は通常のコピー動作に従う

1つの修正済みソースが複数のプロジェクト側ファイルに対応する場合、すべてを差し替えてください。

### 複数候補の扱い

プロジェクト側の1ファイルに対して、異なる複数の修正元が一致すると判定された場合、そのファイルは上書きしないでください。

対象ファイルと修正元候補をCSVに記録し、ほかのファイルの処理は継続してください。

### 対応ファイルが存在しない場合

DB側・プロジェクト側のどちらに対応ファイルが存在しなくても、エラーにはしません。

差し替え対象が0件でも正常終了です。

## 8. エラー処理

**差し替え開始前のエラー**

以下の場合は全体失敗として、プロジェクト側のファイルを一切変更しないでください。

- 設定ファイルの読み込み失敗
- SVNからの取得失敗
- 共有フォルダの検索・読み取り失敗
- プロジェクト側フォルダの検索失敗
- 照合に必要なファイルの1行目の読み取り失敗
- 実行ログファイルの作成失敗

**差し替え開始後のエラー**

個別ファイルの上書きに失敗した場合、そのファイルをエラーとして記録し、残りのファイルの処理を継続してください。

読み取り専用属性を自動解除しないでください。

成功済みの差し替えを元に戻す必要はありません。

## 9. CSVログ

### 9.1 保存場所

ログは、引数で指定されたプロジェクトフォルダの**親フォルダ直下**に作成してください。

プロジェクト内部にはログを作成しないでください。

例：
```yaml
C:\Work\
├─ ProjectA\
└─ ProjectA_20261013_053000_SUCCESS.csv
```

ファイル名にはプロジェクト名と実行日時を含めます。

### 9.2 実行結果の区分

| 状態   | ファイル名の末尾       |
| ---- | -------------- |
| 正常終了 | `_SUCCESS.csv` |
| 一部失敗 | `_PARTIAL.csv` |
| 全体失敗 | `_ERROR.csv`   |

実行開始時点で `_ERROR.csv` を生成してください。

処理を完了した場合のみ、必要に応じて `_SUCCESS.csv` または `_PARTIAL.csv` にリネームしてください。

途中で異常終了・強制終了した場合は `_ERROR.csv` が残るようにしてください。

ログ作成に失敗した場合は、差し替えを開始しないでください。

過去のログは本ツールでは削除しません。ログの削除は別の連続実行ツールが担当します。

### 9.3 CSV形式

- UTF-8（BOM付き）
- カンマ区切り
- ヘッダー行あり
- Python標準の `csv` モジュールを使用
- Excelでの閲覧を想定

最低限、次の情報を記録してください。

- プログラムNo（1行目）
- 修正元ファイルのパス
- 差し替え先ファイルのパス
- 処理結果
- エラー内容

正常に差し替えたファイルも、失敗したファイルも1件ずつ記録してください。

全体失敗の場合は、該当しない項目を空欄にし、エラー原因を1行として記録してください。

差し替え対象が0件の場合は、ヘッダーのみのCSVで構いません。

成功件数・失敗件数などの集計行はCSVには追加しないでください。

### 9.4 コンソール表示

処理終了時に以下を表示してください。

- 差し替え成功件数
- 差し替え失敗件数
- 最終結果（SUCCESS／PARTIAL／ERROR）
- ログファイルの保存場所

連続実行ツールはログファイル名と存在有無で状態を判定します。終了コードによる状態判定を前提としないでください。

## 10. 処理性能

修正元DBとプロジェクト側は、それぞれ数百〜1,000件台程度のファイルを想定します。

不必要にファイル全体を読み込まず、ファイル名・拡張子で候補を絞ったうえで、必要なファイルの1行目を比較する構成を検討してください。

過度な並列処理や複雑な最適化は不要です。

## 11. 設定ファイルとexe化

`config.ini` はPythonスクリプトと同じフォルダに配置してください。

実行時のカレントディレクトリに依存せず、スクリプト本体の配置場所から読み込んでください。

将来exe化しても、exeファイルと同じフォルダに置いた `config.ini` を参照できるようにしてください。

## 12. 開発の進め方

**最初から全コードを書き始めないでください。**

まず本仕様を確認し、社内固有のファイル名の命名規則について私に質問してください。

命名規則が明確になっていない状態で照合ロジックを推測・実装することは禁止です。

命名規則について回答した後、処理フローとファイル名の照合アルゴリズムを提示し、私の確認を得てから実装してください。

その後、実装・動作確認・連続実行ツールへの組み込みを進めます。

私が明示した仕様は勝手に変更しないでください。不明点や矛盾があれば、実装前に質問してください。

それでは、まずファイル名の命名規則について質問してください。

Excel仕様書を情報の欠落・改変・推測なくJSONとMarkdownへ変換するPythonツールの開発指示。赤字・RichText・結合セル・数式の保持と整合性検証を含むPhase 1。

Excel仕様書 AI向け変換ツール 開発指示（Phase 1）

1. 開発目的

Excelで作成されたソフトウェア仕様書を、VS Code上のGitHub CopilotなどのAIが解析しやすい形式へ変換するPythonツールを開発してください。

入力はExcelファイル、出力はMarkdownファイルおよびJSONファイルとします。

本ツールの最優先事項は、元Excelに記載された情報を欠落・改変・推測せずに取り出すことです。

将来的には、仕様書の構造解析、C言語ソースコードとの仕様照合、テスト設計などへ活用します。

今回はPhase 1として、情報抽出と正確性の検証に限定してください。

2. 開発環境

* OS：Windows 11
* 言語：Python 3
* 開発環境：VS Code
* AI開発支援：GitHub Copilot
* Excelデスクトップ版：インストール済み
* 外部Pythonパッケージ：導入可能
* 基本ライブラリ：openpyxl 3.1以降
* テスト：pytest

まずはPythonスクリプトとして動作する構成としてください。GUIは不要です。

Excel自体を起動せずに処理できる構成を優先してください。

3. 入力仕様

対象ファイル

* .xlsx
* .xlsm

.xlsなどの旧形式はPhase 1の対象外です。

最初は単一ファイル指定に対応してください。フォルダ一括変換は将来拡張とします。

対象範囲

* 全ワークシート
* 全ての値を持つセル
* 非表示シート
* 非表示行・列
* 結合セル
* 数式セル

空白セルは原則出力不要ですが、結合範囲の情報は必ず保持してください。

図形、画像、グラフの内容は解析対象外とします。

元Excelファイルは絶対に上書き・変更しないでください。マクロも実行しないでください。

4. セル情報の抽出仕様

4.1 セルの基本情報

値を持つ各セルについて、以下の情報を取得してください。

* シート名
* セル番地（例：D15）
* 元の値
* データ型
* 文字列の場合は全文
* セル内改行
* 結合範囲
* セル全体の文字色情報
* セル内の部分文字色情報

文字列内の空白、タブ、改行、記号は変更しないでください。

前後の空白の自動削除や、改行の自動置換は禁止します。

4.2 結合セル

結合セルがある場合、結合範囲と代表セルを記録してください。

例：

* 結合範囲：B3:D3
* 代表セル：B3
* 値：電源制御仕様

結合範囲内の他のセルへ、代表セルの値をコピーしないでください。

全ての結合範囲をJSONに保持してください。

4.3 赤字の検出

赤字は以下の両方に対応してください。

1. セル内の全文が赤字
2. セル内の一部分だけが赤字

一つのセル内で通常色と赤字が混在する場合、文字列を書式単位で分割して記録してください。

openpyxlのrich_text=Trueを使用し、CellRichTextとTextBlockを考慮した実装としてください。

セル全体のフォント色と部分文字列のフォント色を区別してください。

部分文字列に色指定がない場合は、継承関係を考慮してください。

色の情報は、可能な限り以下を保持してください。

* RGB/ARGB
* Theme色
* Indexed色
* Tint
* 判定結果（red / not_red / unknown）

赤色と判定する具体的な色コードは設定可能にしてください。

初期設定では少なくとも FF0000 と C00000 を対象としてください。

Theme色やIndexed色は、正しく解決できる場合のみRGBへ変換してください。解決できない色を勝手に通常色として扱わず、unknownとして記録してください。

赤字を「変更箇所」「重要事項」などと自動解釈しないでください。

なお、条件付き書式によって表示上のみ赤字になるケースについては、Phase 1では完全対応を必須としません。対象シートに条件付き書式が存在する場合、表示色を再現できていない可能性を警告してください。

4.4 セル内改行

セル内の改行を必ず保持してください。

例：

条件1：車速が0
条件2：電圧が9V未満
条件3：100ms継続

この文章を1行に連結したり、箇条書きに自動変換したりしないでください。

元データの文字列と、JSONから再構築した文字列が完全一致することを検証してください。

4.5 数式

数式セルでは以下を取得してください。

* 数式そのもの
* 保存済み計算結果（取得できる場合）
* 計算結果を取得できたかどうか

必要に応じてdata_only=Falseとdata_only=Trueで別々にブックを読み込んでください。

openpyxlで数式を再計算しないでください。

保存済み計算結果がNoneの場合、未計算と空結果を確実に区別できないことがあるため、その状態を正直に記録してください。

5. JSON出力仕様

JSONは、抽出した情報を正確に保存するための基準データとして扱います。

以下のような構造を基本としてください。

{
  "schema_version": "1.0",
  "source_file": "ECU仕様書.xlsx",
  "sheets": [
    {
      "name": "電源制御",
      "state": "visible",
      "merged_ranges": [
        "B3:D3"
      ],
      "cells": [
        {
          "coordinate": "D15",
          "value_type": "string",
          "text": "車速が0\n電圧が9V未満",
          "segments": [
            {
              "text": "車速が0\n",
              "start": 0,
              "end": 5,
              "is_red": false,
              "red_status": "not_red"
            },
            {
              "text": "電圧が9V未満",
              "start": 5,
              "end": 13,
              "is_red": true,
              "red_status": "red"
            }
          ]
        }
      ]
    }
  ]
}

上記は構造の参考例です。文字位置などの数値は実データから正しく算出してください。

設計時には以下の条件を満たしてください。

* segmentsを順番に結合すると元文字列と完全一致する
* 文字位置の開始・終了はPython文字列インデックス基準で統一する
* 通常色、赤字、色不明を区別する
* 数値、日付、真偽値、Excelエラー値、数式を区別する
* JSONに直接格納できないデータ型は明示的な形式でシリアライズする
* 元セル番地を失わない
* 元のシート順を維持する
* JSONスキーマの仕様をドキュメント化する

必要であれば、上記JSON構成は改善して構いません。ただし、情報の正確性と後方互換性を意識してください。

6. Markdown出力仕様

MarkdownはGitHub CopilotなどのAIが読み取るためのファイルとします。

Phase 1ではExcelの複雑な表構造を推測しないでください。

次の情報を含めてください。

* 元Excelファイル名
* シート名
* セル番地
* セルの内容
* 赤字部分の情報
* 結合範囲の情報

例：

# 電源制御
元ファイル：ECU仕様書.xlsx
## セル D15
車速が0
電圧が9V未満
赤字部分：
- 電圧が9V未満

上記は表示例です。

実装では元文字列と注釈を明確に区別してください。

赤字を示す記号を元文字列の中に挿入して内容を変更するのではなく、別途注釈する方法を優先してください。

Markdownのコードフェンス等を用いる場合は、元文字列内の記号との衝突も考慮してください。

Phase 1で実施しないこと

* 見出しの意味的な自動推定
* 表構造の自動解析
* 仕様内容の要約
* AIによる文章の補正
* 条件式の書き換え
* 自然言語の意味解釈
* 画像認識

これらはPhase 2以降の対象です。

7. 出力ディレクトリ

以下を基本構成とします。

output/
  ECU仕様書/
    index.md
    sheets/
      001_電源制御.md
      002_異常判定.md
    data/
      001_電源制御.json
      002_異常判定.json
    conversion_report.md

同名シートやファイル名の不正文字によって出力が衝突しないようにしてください。

index.mdには元ファイル情報と各シートへのリンクを出力してください。

conversion_report.mdには以下を出力してください。

* 変換対象ファイル
* シート数
* 抽出セル数
* 赤字を含むセル数
* 結合範囲数
* 警告件数
* エラー内容
* 検証結果

出力はUTF-8とし、JSONでは日本語をUnicodeエスケープせず保存してください。

8. 品質検証

情報の欠落を防ぐため、変換後に検証処理を実施してください。

最低限、以下をチェックしてください。

1. 元ExcelとJSONの値を持つセル数が一致する
2. セル番地が一致する
3. 文字列が完全一致する
4. セル内改行が一致する
5. RichTextの各セグメントを連結すると元文字列になる
6. 結合範囲が一致する
7. シート数とシート名が一致する
8. JSONとして正常に読み込める
9. Markdownの全セルに元セル番地からの追跡手段が存在する

赤字の検出については、サンプルExcelを使用して期待値との一致を確認してください。

実際の表示色を判定できなかった場合、正常判定にせず、検証結果に制限事項を明記してください。

9. エラー処理

次のケースを考慮してください。

* ファイルが存在しない
* ファイルが破損している
* 対応していないファイル形式
* シートに値が存在しない
* 異常な書式情報
* 色情報を解決できない
* 保存済み数式結果が存在しない、または空である
* 出力フォルダへの書き込みに失敗する

処理できない場合は原因を明示してください。

一部のセルだけ処理できない場合は、黙って読み飛ばさず、セル番地を含む警告を残してください。

10. テスト仕様

pytestで自動テストを作成してください。

実際のExcelファイルを生成するテストを含めてください。

最低限、以下のケースを検証します。

* 通常の文字列
* 全文赤字
* 一部のみ赤字
* 赤字と通常色が交互に現れる
* 改行を含むセル
* 改行を含む部分赤字
* 結合セル
* 数値セル
* 真偽値セル
* 日付セル
* 数式セル
* 複数シート
* 非表示シート
* 非表示行・列
* 空のシート
* 文字色情報が取得できないセル
* 不正な入力ファイル

特に、元文字列とJSONから復元した文字列の完全一致テストは必須とします。

テストが失敗した場合、原因を修正したうえで再実行してください。

11. 実装方針

保守性と今後の拡張性を重視してください。

次の処理を分離した構造にしてください。

* Excel読み込み
* セル情報抽出
* 文字色解析
* JSON生成
* Markdown生成
* 品質検証
* ログ生成

Pythonの型ヒントを使用してください。

例外処理を適切に実装してください。

不要な外部依存は増やさないでください。

変換結果が毎回同じになるよう、出力順序を固定してください。

12. 納品物

以下を作成してください。

1. 実行可能なPythonコード一式
2. requirements.txt
3. README.md
4. pytestのテストコード
5. サンプルExcel生成コード
6. JSONスキーマの説明
7. Phase 1の制限事項一覧

READMEには以下の情報を記載してください。

* セットアップ方法
* 実行方法
* 入力ファイルの指定方法
* 出力先の指定方法
* 出力ファイルの読み方
* テスト方法
* 対応していないExcel機能

13. 作業の進め方

最初にプロジェクト構成と内部データモデルを簡潔に設計してください。

その後、実際にコードを実装してください。

設計説明だけで終了しないでください。

次の順番を推奨します。

1. JSONへセル情報を抽出する機能
2. 全文赤字・部分赤字の解析機能
3. 結合セルとセル内改行の保持
4. JSONからMarkdownを生成する機能
5. 変換品質検証
6. 自動テスト
7. README作成

各段階で動作確認してください。

不明確な点は、元データの保存を優先する方針で合理的に設計してください。判断した仕様はREADMEに記載してください。

今回の完成条件は、Excelファイルを指定するとJSONとMarkdownが生成され、元Excelとの整合性検証が成功することです。

Phase 2の構造解析には着手せず、Phase 1を完成させてください。

Windows 11・Pythonで画面と一言メモを記録し、VS Code + GitHub Copilotによる業務手順書作成につなげるローカルツールの開発依頼。

Windows 11上で動作する、業務手順書作成を支援するための「作業キャプチャ記録ツール」を作成してください。
このツールの目的は、単なるスクリーンショット取得ではありません。
作業者が実際の業務操作をしながら、
* スクリーンショット
* 操作内容の短いメモ
* 注意事項
* 確認ポイント
* エラー情報
を簡単に記録し、その記録結果を後からVS Code + GitHub Copilotに読み込ませることで、AIがMarkdown形式の業務手順書を効率よく作成できる状態にすることが目的です。
最終的にAIが手順書を作りやすいことを最優先に、データ構造、ファイル構成、UI、出力形式を設計してください。
1. 開発環境
以下を前提としてください。
* OS: Windows 11
* Python利用可能
* 外部Pythonパッケージ導入可能
* Excel等のOfficeアプリも利用する業務環境
* VS Code利用可能
* GitHub Copilot利用可能
* 外部AI APIは使用しない
* ツール自体にはAI機能を持たせない
* AI処理は後段のVS Code + GitHub Copilotに任せる
Pythonを使用して開発してください。
GUIについては、保守性と実装容易性を考慮して適切なライブラリを選定してください。
候補としてPySide6などを想定していますが、より適切なものがあれば提案してください。
2. 基本思想
重要なのは、
「人間がきれいな文章を書く」のではなく、
「人間は作業しながら最低限の情報だけ記録し、後からAIが正式な手順書に整形する」
という考え方です。
作業者の負担はできるだけ小さくしてください。
理想としては、
1. 作業開始
2. 実際の業務操作
3. ホットキー押下
4. スクリーンショット取得
5. 一言メモ入力
6. 保存
7. 次の操作
という流れで記録できることを目指します。
3. 基本機能
3.1 セッション開始
ツール起動後、「新規記録開始」ができるようにしてください。
開始時には最低限、
* 手順書タイトル
* 保存先フォルダ
* 任意の補足情報
を入力できるようにしてください。
例：
手順書タイトル：
設定値ツール 使用手順
保存先：
C:\Work\Manual\SettingTool
補足：
新人向けの基本操作手順
記録開始後は、ツール本体を最小化またはタスクトレイ常駐できるようにしてください。
4. キャプチャ機能
グローバルホットキーでスクリーンショットを取得できるようにしてください。
例：
Ctrl + Shift + F8
ホットキーは設定変更可能にしてください。
キャプチャ方法として最低限、
* 全画面
* アクティブウィンドウ
に対応してください。
可能であれば将来的に、
* 指定範囲
* 指定ウィンドウ
にも拡張できる設計にしてください。
キャプチャ画像はPNG形式で保存してください。
ファイル名は、
step_001.png
step_002.png
step_003.png
のような連番にしてください。
5. キャプチャ直後の入力画面
スクリーンショット取得後、小さな入力ウィンドウを表示してください。
できるだけ作業の邪魔にならないUIにしてください。
入力項目として以下を用意してください。
必須
操作メモ
短い文章を入力します。
例：
INPUT帳票を選択する
実行ボタンを押す
設定値が表示されることを確認する
ここでは文章の完成度を求めません。
AIが後から文章化する前提です。
種類
以下から選択できるようにしてください。
* 操作
* 確認
* 注意
* エラー
* 補足
初期値は「操作」にしてください。
キーボード操作だけでも素早く選択できるようにしてください。
6. 任意入力項目
必要に応じて以下も記録できるようにしてください。
確認ポイント
例：
ファイル名が画面上部に表示されていること
注意事項
例：
ここでは「自動」を選択しない
エラー時の補足
例：
ファイル形式がxlsの場合は読み込みエラーになる
理由・背景
例：
後工程でこのファイルを使用するため
これらはすべて任意入力とします。
通常は「操作メモだけ入力してEnter」で保存できるくらい軽量にしてください。
7. 保存・キャンセル・撮り直し
キャプチャ後は以下の操作ができるようにしてください。
* 保存
* キャンセル
* 撮り直し
可能であればショートカットキーも設定してください。
例：
Enter：保存
Esc：キャンセル
8. 画像への簡易マーキング
キャプチャ画像に対して簡単な注釈を付けられる機能を用意してください。
最低限、
* 四角枠
* 矢印
* 番号
* ぼかしまたは塗りつぶし
を検討してください。
ただし、この機能のためにツールが複雑になりすぎる場合は、最初のバージョンでは後回しにして構いません。
設計上は将来追加できるようにしてください。
特に「どこをクリックするのか」を画像上で示しやすいことを重視します。
9. 手順一覧画面
記録した内容を一覧表示できる画面を作成してください。
例：
01　ツールを起動する
02　INPUTボタンを押す
03　INPUT帳票を選択する
04　設定内容を確認する
05　実行ボタンを押す
各ステップについて、
* サムネイル
* 種類
* メモ
* 確認ポイント
* 注意事項
を確認できるようにしてください。
さらに、
* 編集
* 削除
* 画像差し替え
* 並び替え
ができるようにしてください。
並び替えはドラッグ＆ドロップが理想です。
並び替え後にはstep番号を自動的に振り直してください。
10. AI利用を意識した保存形式
ここは非常に重要です。
後からGitHub Copilotが内容を理解しやすいように、人間向けだけでなく機械可読な形式でも情報を保存してください。
最低限、
session.json
を作成してください。
例：
{
  "title": "設定値ツール 使用手順",
  "description": "新人向けの基本操作手順",
  "steps": [
    {
      "step": 1,
      "type": "operation",
      "note": "設定値ツールを起動する",
      "check_point": "",
      "warning": "",
      "error_note": "",
      "reason": "",
      "image": "captures/step_001.png"
    },
    {
      "step": 2,
      "type": "operation",
      "note": "INPUT帳票を選択する",
      "check_point": "選択したファイル名が表示されること",
      "warning": "",
      "error_note": "",
      "reason": "",
      "image": "captures/step_002.png"
    }
  ]
}
JSONのキー名は英語で構いません。
値として入力される文章は日本語を想定してください。
11. Markdownの作業記録を自動生成
AIに渡しやすくするため、
notes.md
も自動生成してください。
例：
# 設定値ツール 使用手順

## Step 1

種類: 操作

設定値ツールを起動する。

![Step 1](captures/step_001.png)

## Step 2

種類: 操作

INPUT帳票を選択する。

確認ポイント:
選択したファイル名が表示されること。

![Step 2](captures/step_002.png)
このnotes.mdは正式な手順書ではありません。
あくまで、
「AIが正式な手順書を作るための原始データ」
として扱います。
そのため文章の美しさよりも、情報が欠落しないことを重視してください。
12. 最終的なフォルダ構成
記録完了後は以下のような構成になるようにしてください。
SettingToolManual/
│
├─ captures/
│   ├─ step_001.png
│   ├─ step_002.png
│   ├─ step_003.png
│   └─ step_004.png
│
├─ session.json
├─ notes.md
├─ manual.md
└─ copilot_prompt.md
manual.mdはAIが正式な手順書を作成するための出力先です。
初期状態では空ファイルまたはテンプレートだけでも構いません。
13. Copilot用プロンプトの自動生成
記録終了時に、
copilot_prompt.md
を自動生成してください。
内容は例えば以下のようなものにしてください。
# 手順書作成依頼

このフォルダには業務操作を記録したデータがあります。

以下を確認してください。

- session.json
- notes.md
- capturesフォルダ内のスクリーンショット

これらを基に、新人でも実施できる正式な業務手順書を
manual.md
に作成してください。

## 作成ルール

- Markdown形式で作成する
- 手順は番号付きで整理する
- 必要なスクリーンショットを適切な位置に掲載する
- 操作と確認ポイントを区別する
- 注意事項は目立つ形式にする
- エラー情報がある場合は対処方法として整理する
- 操作理由が記録されている場合は必要に応じて補足する
- 元データに存在しない仕様を勝手に推測しない
- 不明点は「要確認」と記載する
- ボタン名、メニュー名、ファイル名などは元の表記を維持する
- 冗長すぎない業務手順書にする
14. VS Code連携
記録終了後に、
「VS Codeで開く」
ボタンを用意してください。
押すと今回の手順書フォルダをVS Codeで開いてください。
可能であれば、
copilot_prompt.md
も同時に開いてください。
GitHub Copilot Chatへの自動送信までは必須ではありません。
VS Codeを開いた後に、人間がcopilot_prompt.mdの内容をCopilotへ入力する運用で構いません。
15. 記録終了処理
「記録終了」を押すと、
1. step番号の整合性確認
2. session.json更新
3. notes.md再生成
4. copilot_prompt.md生成
5. manual.mdがなければ作成
6. 完了画面表示
を行ってください。
完了画面には、
* 保存先を開く
* VS Codeで開く
* 記録を再編集する
を表示してください。
16. 後から編集可能にする
一度終了したセッションも再度読み込めるようにしてください。
session.jsonを読み込むことで、
* 既存ステップ表示
* メモ修正
* 画像差し替え
* 手順追加
* 手順削除
* 並び替え
ができるようにしてください。
つまりsession.jsonを、その手順書プロジェクトのマスターデータとして扱ってください。
17. データ保全
業務利用を想定しているため、記録途中でツールが終了してもできるだけデータを失わないようにしてください。
各ステップ保存時にsession.jsonを更新してください。
一時ファイルを利用する場合は、安全に置換してください。
JSON破損を避けるため、
一時ファイルへ書き込み
→正常終了後に置換
などの方法を検討してください。
18. セキュリティ・業務利用上の配慮
このツールから、
* インターネット通信
* 外部サーバーへのアップロード
* 外部AI APIへの送信
は一切行わないでください。
すべてローカルPC上で完結してください。
また、キャプチャ画像には機密情報が含まれる可能性があるため、
* 外部送信しない
* 自動クラウドアップロードしない
* テレメトリを送信しない
構成にしてください。
19. MVPとしての優先順位
いきなりすべて実装して複雑化しないでください。
まず以下をMVPとして完成させてください。
優先度A：
* 新規セッション作成
* タスクトレイ常駐
* グローバルホットキー
* スクリーンショット取得
* 一言メモ入力
* 種類選択
* PNG保存
* session.json保存
* notes.md生成
* 一覧画面
* 編集
* 削除
* 並び替え
* copilot_prompt.md生成
* VS Codeでフォルダを開く
優先度B：
* 確認ポイント
* 注意事項
* エラー情報
* 理由・背景
* セッション再読み込み
優先度C：
* 画像マーキング
* ぼかし
* 範囲キャプチャ
* 詳細設定
まず優先度Aを確実に動作させ、その後B、Cへ拡張してください。
20. UI設計方針
業務中に頻繁に使用するため、UIはシンプルにしてください。
特にキャプチャ後の入力は、
「文字入力してEnter」
だけでも完結できることを重視してください。
マウス操作を何度も要求しないでください。
基本動作はキーボード中心でも操作できるようにしてください。
21. コード設計
後から機能追加しやすいように、責務を分離してください。
例えば、
* GUI
* キャプチャ処理
* ホットキー処理
* セッション管理
* JSON保存
* Markdown生成
* VS Code起動
などを分離してください。
巨大な1ファイルにすべて実装しないでください。
適切なモジュール構成を提案してください。
22. 開発の進め方
いきなり大量のコードを書き始めず、まず以下を提示してください。
1. 要件整理
2. 技術選定
3. フォルダ構成
4. データ構造
5. 画面構成
6. クラス・モジュール構成
7. MVPの実装順序
8. 想定されるリスク
その設計を示した後、MVPの実装を開始してください。
実装中に仕様上の曖昧な点があった場合は、極端に重要なもの以外は合理的な案を選び、READMEに判断内容を記録してください。
23. 最終目標
このツールの価値は、
「スクリーンショットを撮ること」
ではなく、
「後からAIが高品質な業務手順書を作れる作業記録を、作業者に負担をかけず収集すること」
です。
常にこの目的を優先して設計してください。
最終的には、
実際の業務を行う
↓
ホットキーで必要な画面を記録
↓
一言メモを残す
↓
記録終了
↓
VS Codeでプロジェクトを開く
↓
GitHub Copilotが画像・メモ・JSONを確認
↓
manual.mdを生成
↓
人間がレビュー
という流れを目指してください。

Python・Tkinter・Excel COMで、フォルダ内のExcelのセル値を横断検索し、結果をxlsxにまとめるツールの作成依頼。

Windows 11上で動作する、Excelファイル専用のGUI GrepツールをPythonで作成してください。

1. 目的

秀丸エディタのGrepのように、指定したフォルダ以下に存在するExcelファイルを再帰的に検索し、指定キーワードを含むセルを一覧化するツールを作りたいです。

検索対象はExcelファイル内の全シート・全使用セルです。

検索結果は新しいExcelファイル（xlsx）として一覧表示してください。

会社PCで使用する社内向けローカルツールです。

⸻

2. 開発環境

OS：
Windows 11

Microsoft Excel：
デスクトップ版がインストール済み

Python：
インストール済み

外部Pythonパッケージ：
pipでインストール可能

実装言語：
Python

Excelの読み込みには、Microsoft Excelそのものを利用できる pywin32 のCOM Automationを基本としてください。

理由は以下です。

* xlsx対応
* xls対応
* xlsm対応
* xlsb対応
* Excelで保存済みの数式計算結果を取得できる
* VBA UDFを含むブックでも、保存済み計算結果なら取得できる
* Excelとの互換性を優先したい

GUIは、追加の大規模フレームワークを必要としない限り、Python標準のTkinterを優先してください。

検索結果xlsxの生成については、実装しやすければopenpyxlを使用して構いません。

⸻

3. 検索対象ファイル

指定されたフォルダおよび、その配下に存在するすべてのサブフォルダを再帰的に検索します。

対象拡張子は以下です。

* .xlsx
* .xls
* .xlsm
* .xlsb

拡張子判定では大文字小文字を区別しないでください。

例：

* TEST.XLSX
* Book.xlsm

なども対象です。

Excelの一時ファイルである

~$xxxx.xlsx

のようなファイルは検索対象から除外してください。

⸻

4. Excelファイルを開く際の重要仕様

このツールは「Grepツール」であり、検索対象Excelの内容を変更したり、処理を実行したりしてはいけません。

Excelファイルは可能な限り読み取り専用で開いてください。

以下を必須とします。

VBAマクロ

VBAマクロを実行しないでください。

COM AutomationでExcelを開く前に、AutomationSecurity等を適切に設定し、VBAマクロを無効化してください。

数式の再計算

絶対に再計算しないでください。

ExcelのCalculationを手動計算モードにしてください。

検索対象とするのは、

「そのExcelファイルが最後に保存された時点で保持している計算結果」

です。

たとえば、

=A1+B1

という数式の保存済み計算結果が300なら、検索対象値は300です。

VBAユーザー定義関数、

=MyFunction(A1)

などが存在する場合も、その関数を実行するのではなく、Excelファイルに保存されている最後の計算結果を検索してください。

外部リンク

外部リンクを更新しないでください。

別Excelファイルやネットワークファイル等への参照が存在していても、検索のために更新してはいけません。

保存済みの値を使用してください。

保存

検索対象となったExcelファイルを、このツールから保存しないでください。

検索終了時にも変更保存確認などを出さずに閉じてください。

⸻

5. Excelアプリケーション

可能であれば、検索専用のExcel.Applicationインスタンスをバックグラウンドで生成してください。

基本的には、

* Visible = False
* DisplayAlerts = False
* ScreenUpdating = False
* EnableEvents = False
* Calculation = Manual
* マクロ無効
* 外部リンク更新なし

としてください。

ただし、処理終了時やキャンセル時、例外発生時にもExcel.exeのプロセスを残さないよう十分注意してください。

try/finally等を使い、確実に、

* Workbook.Close(False)
* Excel.Application.Quit()

を実行してください。

COMオブジェクトについても適切に解放してください。

ユーザーが通常使用している既存のExcelプロセスを終了させないでください。

このツール自身が生成したExcelインスタンスだけを管理してください。

⸻

6. 検索対象シート

以下をすべて検索してください。

* 通常表示シート
* 非表示シート
* VeryHiddenシート

非表示状態を理由に検索対象から除外しないでください。

⸻

7. 検索対象セル

各ワークシートのUsedRangeを検索対象としてください。

Excelの全1048576行×16384列を総当たりする実装にはしないでください。

以下も検索対象です。

* 通常セル
* 非表示行に存在するセル
* 非表示列に存在するセル
* オートフィルター等によって画面上で非表示になっている行のセル

セルが現在Excel画面上で見えているかどうかは検索条件に影響させません。

UsedRange内に存在する値を検索してください。

⸻

8. 検索する値

検索対象は「セルの計算結果・値」です。

数式文字列そのものを検索対象にはしません。

たとえば、

A1に

=B1&C1

と入力され、

計算結果が

ABCDEFG

の場合、

検索キーワード

ABC

ではヒットします。

一方、

検索キーワード

B1&C1

では、計算結果にその文字列が存在しない限りヒットしません。

検索にはValueまたはValue2等を適切に利用してください。

ただし検索結果一覧には、

* 値
* 数式

の両方を記録してください。

⸻

9. 検索方式

GUIから以下の検索方式を選択できるようにしてください。

部分一致

デフォルトです。

キーワード：

ABC

セル：

xxxABCxxx

ならヒットします。

完全一致

キーワード：

ABC

セル：

ABC

だけがヒットします。

xxxABCxxx

はヒットしません。

正規表現

Pythonのreを使用して構いません。

例：

ABC|DEF|GHI

のように指定すれば、ABC、DEF、GHIのいずれかを含むセルを検索できます。

正規表現が不正な場合は検索を開始せず、ユーザーに分かる形でエラー表示してください。

⸻

10. 大文字小文字

GUIに

「大文字小文字を区別する」

チェックボックスを設けてください。

デフォルトはOFFです。

OFFの場合、

* abc
* ABC
* Abc

を同一として扱ってください。

これは、

* 部分一致
* 完全一致
* 正規表現

すべてに適用してください。

正規表現の場合はre.IGNORECASE等を使用して構いません。

⸻

11. 数値等の検索

文字列セルだけでなく、

* 数値
* 日付
* Boolean
* エラー値等

についても、可能な範囲で文字列化して検索できるようにしてください。

None / 空セルは検索不要です。

実装上問題がなければ、セル値を適切にstrへ変換して検索してください。

ただし例外値によって検索全体が停止しないようにしてください。

⸻

12. パフォーマンス

大量のExcelファイルを検索する可能性があります。

可能な限り、

「1セルずつCOM越しにValueを取得する」

実装は避けてください。

COM呼び出し回数を減らすため、可能であればUsedRangeの、

* Value2
* Formula

等を配列として一括取得し、Python側で検索してください。

ただし、

* 1セルしかないUsedRange
* 複数セルのUsedRange

ではCOMの返り値の形式が異なる可能性があるため、その差を正しく処理してください。

速度だけを優先して検索精度を落とさないでください。

⸻

13. GUI

Tkinter等でGUIを作成してください。

最低限、以下を配置してください。

検索フォルダ

テキストボックス

＋

「参照…」

ボタン

フォルダ選択ダイアログで検索開始フォルダを指定できるようにしてください。

検索キーワード

入力欄を設けてください。

検索方式

以下から選択できるようにしてください。

* 部分一致
* 完全一致
* 正規表現

デフォルト：

部分一致

大文字小文字

チェックボックス：

「大文字小文字を区別する」

デフォルトOFF

検索開始

「検索開始」ボタン

キャンセル

「キャンセル」ボタン

検索中のみ有効にして構いません。

キャンセルを押した場合、

現在安全に停止可能なタイミングで検索を終了してください。

Excelプロセスや一時ファイルを残さないようにしてください。

⸻

14. 検索中の進捗表示

GUI上に最低限以下を表示してください。

* 現在処理中のファイル
* 処理済みファイル数
* 全対象ファイル数
* 現在までのヒット件数

例：

処理中: C:\Project\Test\data.xlsx

ファイル: 125 / 430

ヒット: 82件

可能であればProgressBarも追加してください。

GUIが検索中に「応答なし」にならないようにしてください。

検索処理はワーカースレッド等で実行し、GUIのメインスレッドをブロックしない構成にしてください。

ただしTkinter GUIの更新はメインスレッドから行うなど、スレッドセーフに実装してください。

queue等を使用して構いません。

COMをワーカースレッドから使用する場合は、

pythoncom.CoInitialize()

および

pythoncom.CoUninitialize()

等も適切に使用してください。

⸻

15. 検索結果

検索終了後、検索結果をxlsx形式のExcelファイルとして生成してください。

結果ファイルはまず一時ファイルとして生成してください。

検索対象フォルダ内へ自動保存する必要はありません。

ファイル名の例：

ExcelGrep_Result_YYYYMMDD_HHMMSS.xlsx

ただし実体はtempディレクトリ等へ作成して構いません。

⸻

16. 検索結果ExcelのResultsシート

Resultsというシートを作成してください。

以下の列を作ってください。

1. No.
2. ファイルパス
3. ファイル名
4. シート名
5. セル
6. 値
7. 数式

例：

No.	ファイルパス	ファイル名	シート名	セル	値	数式
1	C:\A\Test.xlsx	Test.xlsx	Sheet1	B25	ABCDEF	
2	C:\A\Data.xlsm	Data.xlsm	設定	C10	ABC123	=A10&B10

数式でないセルの場合、「数式」列は空欄で構いません。

⸻

17. ハイパーリンク

検索結果から元Excelファイルを簡単に開けるようにしてください。

最低限、「ファイルパス」列をクリックすると元Excelファイルを開けるハイパーリンクにしてください。

さらに安定して実装可能であれば、

ヒットした、

* 元Excelファイル
* シート
* セル

まで直接ジャンプできるハイパーリンクを設定してください。

直接セルジャンプが環境やExcel仕様上不安定な場合は、無理に複雑な実装をせず、元ファイルを開くハイパーリンクを優先してください。

元Excelファイルに変更を加える必要はありません。

⸻

18. エラー一覧

Errorsという別シートを結果Excelに作成してください。

検索中に以下のようなファイルが存在しても、検索全体を停止してはいけません。

例：

* ファイル破損
* Excelで開けない
* パスワード保護
* アクセス権限なし
* COMエラー
* セキュリティ上開けない
* 古いExcelマクロ等による警告
* その他予期しないエラー

そのファイルだけスキップし、Errorsシートへ記録してください。

最低限以下の列を作ってください。

* No.
* ファイルパス
* ファイル名
* エラー内容

可能ならエラー種別も追加してください。

⸻

19. 検索結果0件

検索結果が0件でも正常終了としてください。

Resultsシートのヘッダーは作成し、

GUIにも、

検索完了：0件

等と表示してください。

⸻

20. 結果表示後の動作

検索終了後、GUI上で、

* ヒット件数
* エラーファイル件数
* 処理したファイル件数

を表示してください。

また、

「結果を開く」

ボタンを設けて、一時生成したxlsxをExcelで開けるようにしてください。

さらに、

「名前を付けて保存」

ボタンを設けてください。

ユーザーが保存先とファイル名を指定し、一時結果xlsxを任意の場所へ保存できるようにしてください。

元のtempファイルを直接編集するのではなく、コピーして保存する方式でも構いません。

⸻

21. 検索対象自身について

結果Excelはtemp領域に生成するため、

ExcelGrep_Result_*.xlsx

という名前だけを理由に検索対象から除外する特殊処理は不要です。

検索開始時に存在している、指定フォルダ配下の対象Excelファイルだけを列挙して検索してください。

⸻

22. ファイルロック

他ユーザーや別プロセスが開いているExcelファイルでも、

読み取り専用で開けるなら検索してください。

読み取り専用でも開けない場合のみErrorsへ記録してスキップしてください。

⸻

23. 元ファイル保護

このツールを使用したことで検索対象Excelの、

* 更新日時
* 内容
* 数式
* マクロ
* 外部リンク
* 計算結果

などが変更されないことを重要視してください。

検索対象Workbookに対してSaveやSaveAsを実行しないでください。

⸻

24. コード構成

すべてを1ファイルへ無理に詰め込まず、保守しやすい構成にしてください。

例えば、

* main.py
* gui.py
* excel_searcher.py
* result_writer.py
* models.py

等に分割して構いません。

ただし必要以上に複雑なアーキテクチャにはしないでください。

小規模な社内ツールとして理解・修正しやすいことを優先してください。

⸻

25. requirements.txt

必要な外部ライブラリをrequirements.txtにまとめてください。

例えば、

* pywin32
* openpyxl

などです。

標準ライブラリはrequirements.txtへ書く必要はありません。

⸻

26. README

README.mdを作成してください。

最低限以下を書いてください。

* ツール概要
* 必要環境
* Pythonバージョン
* 必要ライブラリ
* pip install方法
* 起動方法
* 検索仕様
* 数式についての仕様
* マクロを実行しないこと
* 数式を再計算しないこと
* 検索対象が「保存済みの計算結果」であること
* 対応Excel形式
* エラー時の挙動

⸻

27. セキュリティ・安全性

特に重要です。

このツールは大量の社内Excelを横断検索するため、

「検索するだけで対象Excelに副作用を発生させない」

ことを最優先してください。

したがって、

* VBAマクロを実行しない
* Workbookイベントを実行しない
* 数式を再計算しない
* 外部リンクを更新しない
* 元Workbookを保存しない
* ユーザーの既存Excelプロセスを終了しない

ことを守ってください。

⸻

28. 例外処理

1ファイルの失敗で検索全体を止めない設計にしてください。

ただし、

Excel.Application自体が異常終了したなど、そのまま検索続行できない重大なエラーについては、可能であればExcelインスタンスを安全に作り直して続行してください。

過剰に複雑になる場合は、安全に検索を終了してユーザーへ通知する方式でも構いません。

⸻

29. テスト

最低限、以下のケースをテストしてください。

1. xlsxの通常文字列セル
2. xls
3. xlsm
4. xlsb
5. サブフォルダ内ファイル
6. 非表示シート
7. 非表示行
8. 非表示列
9. フィルターで非表示になった行
10. 数式セル
11. 数式結果への部分一致
12. 数式文字列には存在するが結果には存在しない文字
13. 大文字小文字を無視した部分一致
14. 大文字小文字を区別した検索
15. 完全一致
16. 正規表現
17. 正規表現で複数キーワード
18. 不正な正規表現
19. パスワード等で開けないExcel
20. 破損Excel
21. 検索結果0件
22. 大量セルを含むシート
23. キャンセル
24. 検索終了後にExcel.exeが残らないこと
25. 検索前後で元Excelの内容および更新日時が変化しないこと

⸻

30. 実装時の進め方

いきなり全コードを1回で生成して終了するのではなく、まずこの要求仕様を解析してください。

そのうえで、

1. 実装方針
2. ファイル構成
3. 使用ライブラリ
4. COMを使ったExcel読み込み方法
5. 検索アルゴリズム
6. GUIと検索スレッドの連携方法
7. 検索対象Excelへ副作用を発生させない方法
8. 注意すべきExcel COM特有の問題

を整理してください。

その設計に問題がなければ、そのまま実装を開始してください。

実装後はコードを見直し、特に、

* Excelプロセスリーク
* WorkbookのClose漏れ
* COMオブジェクト解放漏れ
* GUIスレッド関連
* UsedRangeが1セルだけの場合
* Value2が配列にならない場合
* Formulaの配列形式
* 正規表現エラー
* Unicode日本語パス
* 非表示シート
* xls / xlsm / xlsb
* キャンセル途中の後始末

を重点的に確認してください。

最終的に、実際にユーザーが、

python main.py

等で起動して使用できる完成状態まで作成してください。

不明な点があった場合、実装を勝手な仕様で変更せず、要件との整合性を優先してください。

問い合わせや対応履歴の一覧を、分類・件数・再発傾向から見直すためのメモ。

# 一覧データの分類と振り返り

表になっている記録を分類し、傾向や見直しポイントを整理するためのメモです。

詳しいひな形は詳細ページにまとめています。

1行目の開始・終了マーカーを基準に、対応する2ブロックを同じ相対位置で編集するVBA。

# VBA作成依頼：2つの列ブロックを連動して挿入・削除する

Excel VBAで、以下の処理を行うマクロを作成してください。

## 前提
- 対象はアクティブシート
- 1行目に列ブロックの開始・終了を表すマーカー文字列がある
- ブロックAは `BLOCK_A_START` から `BLOCK_A_END` の間
- ブロックBは `BLOCK_B_START` から `BLOCK_B_END` の間
- 2つのブロックは同じ列数で、同じ相対位置の列同士が対応している

## 作りたい機能
1. 選択列と同じ相対位置に、両ブロックで列を挿入する
2. 選択列と同じ相対位置を、両ブロックから削除する

## 安全対策
- 4つのマーカーが見つからなければ中止する
- ブロックの列数が一致しなければ中止する
- 選択列が対象範囲外なら中止する
- 実行前に確認メッセージを表示する
- ScreenUpdating / EnableEvents は最後に必ず元へ戻す
- 外部通信・外部ファイル操作は行わない

## コード方針
- マーカー文字列は定数で管理する
- 検索、検証、挿入、削除を関数に分ける
- 初心者が保守できる日本語コメントを入れる

列操作やコピーで崩れた条件付き書式を、定義済みルールから復元するVBAと設計案。

# VBA作成依頼：条件付き書式を安全に再設定する

Excel VBAで、対象範囲の条件付き書式を定義済みルールから再構築してください。

## やりたいこと
- コピー・列挿入・列削除で条件付き書式が分割または重複する問題を直す
- 対象範囲の適用先を正規化する
- 必要な場合だけ既存ルールを削除し、同じ優先順位で再設定する

## 条件
- 対象シート・範囲・数式・色は定数または設定表にまとめる
- 再実行してもルールが重複しない
- 処理前後のルール数と適用範囲を確認できる
- エラー時は変更内容と原因を表示する
- 外部通信・外部ファイル操作は行わない

## あわせて比較してほしい対策
- Excelテーブルを使う
- 名前付き範囲を使う
- AppliesToだけを修復する
- シート変更イベントでの自動修復は必要か

初心者向けに、各方式のメリットと壊れやすい場面も説明してください。

指定列だけを抽出し、並べ替えて別CSVへ出力する、外部通信なしの汎用スクリプト。

# Python作成依頼：CSVを安全に整形する

標準ライブラリだけを使い、CSVを整形するコマンドラインツールを作ってください。

## 入力
- 入力CSV、出力CSV、抽出列名、並べ替え列を引数で受け取る
- 文字コードはUTF-8（BOM付きも許容）

## 処理
- 指定列の存在を検証する
- 指定した列だけを指定順で抽出する
- 日付列または文字列列で昇順・降順を選んで並べ替える
- 元ファイルは変更しない

## 安全対策
- 出力先が既にある場合は確認する
- 不正な行数と内容をログに出す
- 外部通信なし、追加ライブラリなし
- ダミーデータのテストケースを付ける

Windowsで初心者が実行できるREADMEも作ってください。

変更予定を一覧表示してから実行し、衝突と取り消しに備えるPowerShellツール。

# PowerShell作成依頼：ファイル名を安全に一括変更する

指定フォルダ直下のファイル名をルールに沿って変更するスクリプトを作ってください。

## 必須機能
- 対象拡張子、接頭辞、連番の桁数を引数で受け取る
- 最初は必ずドライランで「変更前 → 変更後」を一覧表示する
- 明示的な実行オプションがある場合だけ変更する
- 同名ファイルがある場合は一切変更せず中止する
- サブフォルダは既定で対象外にする

## 復旧
- 実行日時と変更対応表をCSVで保存する
- 対応表から元の名前へ戻す方法も用意する

外部通信は行わず、初心者向けの使い方と注意点を付けてください。

フォルダ配下の複数Excelから条件一致するシート・行を探し、1つのExcelへ集約するツール作成プロンプト。

# Excel複数ファイル一括情報抽出ツール 作成プロンプト

あなたは業務効率化ツールの設計・開発を支援するソフトウェアエンジニアです。

指定フォルダ以下に存在する複数のExcelファイルから、条件に一致するシート・行を検索し、必要な情報を1つのExcelファイルに集約するツールを作成したいです。

## 実現したい処理

1. ユーザーが検索対象となるフォルダを指定する
2. 指定フォルダだけでなく、すべてのサブフォルダを再帰的に検索する
3. 配下に存在するExcelファイルを検索対象とする
4. 各Excelファイルの全シートを確認する
5. 指定したセルに指定文字列が記載されているシートだけを処理対象とする
6. 対象シート内で、指定した列を検索する
7. その列の値が指定文字列と一致する行を抽出する
8. 該当行から指定した列・範囲の情報を取得する
9. すべてのExcelファイルから取得した情報を1つのExcelファイルにまとめる
10. 抽出した情報には、取得元を追跡できるよう以下の情報も追加する

- 元Excelファイル名
- 元シート名
- 必要であれば元ファイルのフルパス
- 必要であれば元Excel上の行番号

## ユーザーが指定できるようにしたい条件

以下については、特定案件専用の値をプログラム内に直接埋め込まず、後から簡単に変更できる構成にしてください。

- 検索対象フォルダ
- 対象とするExcelファイルの拡張子
- シート判定に使用するセル
- シート判定に使用する文字列
- 行検索に使用する列
- 行検索に使用する文字列
- 抽出する列またはセル範囲
- 出力先Excelファイル名
- 出力先フォルダ

## 例

例えば以下の条件を設定できるようにします。

### シート判定

- セル：B2
- 条件：B2の値が「対象帳票」と完全一致するシート

### 行検索

- 検索列：D列
- 条件：D列の値が「問い合わせ」と完全一致する行

### 抽出

- 該当行のA列～H列

この場合、フォルダ以下のすべてのExcelファイルを検索し、B2 = 「対象帳票」となっているシートについて、D列 = 「問い合わせ」となっている行をすべて抽出してください。

出力Excelには、以下のように出力してください。

- 元ファイル名
- 元シート名
- 元ファイルパス
- 元行番号
- A列
- B列
- C列
- ...
- H列

## 例外処理

実際の業務フォルダを対象にするため、以下も考慮してください。

- Excel以外のファイルが存在する
- サブフォルダが複数階層存在する
- 一時ファイル「~$～」が存在する
- パスワード保護などで開けないExcelが存在する
- 壊れていて読み込めないExcelが存在する
- 非表示シートが存在する
- 空白セルが存在する
- 同じシート内に条件一致する行が複数存在する
- 1ファイル内に対象シートが複数存在する
- 数式セルが存在する
- 出力先Excelそのものを再検索してしまう可能性がある

1つのファイルでエラーが発生しても処理全体を停止させず、エラーになったファイルを記録して残りのファイルの処理を継続してください。

## 処理結果

正常終了時には以下が分かるようにしてください。

- 検索したExcelファイル数
- 条件に一致したシート数
- 抽出した行数
- 読み込みに失敗したファイル数

読み込み失敗などがあった場合は、ファイル名・ファイルパス・エラー内容をログとして確認できるようにしてください。

## 開発方針

いきなりコードを書き始めないでください。

まず、この要求を実現するために不足している仕様や、実装前に決める必要がある項目を質問してください。

特に、VBA、Python、PowerShell、その他の方法のどれが適しているかについて、利用環境、配布方法、Excelファイルの形式、処理対象ファイル数、実行速度、保守性を考慮して提案してください。

仕様が確定したら、以下の順番で作成してください。

1. 処理フロー
2. 採用技術とその理由
3. ファイル構成
4. 設定値の管理方法
5. エラー処理
6. 実装
7. 使用方法
8. テスト方法

業務で継続利用するツールであるため、コードの短さよりも、読みやすさ・安全性・変更しやすさを優先してください。

画面キャプチャ、画像解析、チケット登録までの流れを段階PoCで整理するための設計メモ。

# 画面キャプチャからAI解析してチケット化する常駐ツール 作成プロンプト

あなたはWindowsデスクトップアプリ、VS Code拡張機能、GitHub Copilot、マルチモーダルAI連携に詳しいソフトウェアアーキテクト兼エンジニアです。

業務用の「画面キャプチャからタスクを自動抽出し、チケット化する常駐ツール」を新規に設計・実装したいです。

いきなり完成版を実装するのではなく、技術的に成立するかを公式仕様で確認し、小さなPoCから段階的に実装してください。

## 1. 実現したいこと

Windows上で常駐する小型ツールを作成します。

ユーザーがこのツールから画面の一部をキャプチャすると、その画像をAIに解析させ、以下を抽出します。

- やるべきこと
- 期限
- 必要に応じて担当者
- 補足情報

AI解析後は確認画面を表示し、ユーザーが必要であれば内容を修正できるようにします。

ただし、毎回ユーザーが「登録」ボタンを押す必要はありません。

一定時間ユーザー操作がなければ、AI解析結果を自動的にチケットとして登録し、登録完了後は再びキャプチャ待機状態へ戻してください。

普段は以下の半自動運用を目標とします。

1. キャプチャ
2. AI解析
3. 短時間だけ確認画面を表示
4. ユーザーが何もしなければ自動登録
5. キャプチャ待機

## 2. 全体フロー

以下の流れを実現したいです。

1. 常駐Windowsツール
2. ツール自身で画面範囲をキャプチャ
3. キャプチャ画像を取得
4. VS Code拡張機能へ画像を渡す
5. GitHub Copilot
6. 利用可能なマルチモーダルAI
7. 画像解析
8. タスク・期限などを構造化
9. VS Code拡張機能から常駐ツールへ解析結果を返す
10. 確認画面を表示
11. ユーザーが必要なら修正
12. 一定時間操作がなければ自動登録
13. チケット作成
14. キャプチャ待機状態へ戻る

## 3. AI利用環境

会社からGitHub Copilotのアカウントが付与されています。

VS Code上ではGitHub CopilotおよびCopilot Chatを利用できます。

ただし、会社環境の制約によりGitHub CopilotのAPIを直接利用することはできません。

そのため、通常のWeb API経由ではなく、以下の構成を検討したいです。

1. 常駐Windowsアプリ
2. 自作VS Code拡張機能
3. GitHub Copilot
4. 利用可能なAIモデル

独自のOpenAI APIキー、Anthropic APIキーなどを追加することは前提としません。

会社から与えられているGitHub Copilot環境を利用することを前提にしてください。

## 4. 過去に作成した方式と問題点

以前、一度同様のツールを作成しました。

以前のツールもWindows上に常駐させ、常に最前面に表示して、必要なときにすぐキャプチャできるようにしていました。

しかし、AIへ画像そのものを渡すことができなかったため、以下の構成になりました。

1. キャプチャ画像
2. Windows OCR
3. OCR結果テキスト
4. AI解析

この方式では、以下の問題があり、十分な精度を得られませんでした。

- OCRの誤認識
- 表やレイアウト情報の消失
- 強調表示や吹き出しなどの視覚情報の消失
- 日付や記号の読み取りミス
- OCRできなかった文字がAIに渡らない
- 元画像ならAIが理解できた可能性のある情報が失われる

今回は可能な限り、「OCRしたテキスト」ではなく「元のキャプチャ画像そのもの」をマルチモーダルAIへ入力してください。

## 5. 常駐Windowsツールの要件

Windows上に常駐する小型アプリケーションとして実装してください。

以下の機能を希望します。

- Windows上で常駐できる
- 小型ウィンドウとして表示できる
- 常に最前面表示できる
- 最前面表示ON/OFFを切り替えられる
- タスクトレイへ格納できる
- グローバルショートカットから呼び出せる
- 「キャプチャ」ボタンを配置する
- キャプチャ後は自動的にAI解析へ進む
- AI解析中であることが分かる
- AI解析結果を確認できる
- 登録完了後、自動的に通常の待機状態へ戻る

以前のツールのように、「常に画面の端などに置いておき、必要な情報を見つけたらすぐキャプチャする」という操作性を重視してください。

## 6. キャプチャ機能

キャプチャはこの常駐ツール自身で行ってください。

ユーザーが別途Windows標準のSnipping Toolなどを操作する方式にはしないでください。

基本操作は以下とします。

1. ユーザーが常駐ツールの「キャプチャ」ボタンを押す、またはグローバルショートカットを押す
2. 常駐ツール自身のウィンドウを一時的に非表示にする
3. 画面を範囲選択モードにする
4. ユーザーがマウスドラッグで矩形範囲を選択する
5. 選択範囲を画像として取得する
6. 常駐ツールを再表示する
7. キャプチャ画像をプレビュー表示する
8. 自動的にAI解析を開始する

Escキーでキャプチャをキャンセルできるようにしてください。

以下についても考慮してください。

- マルチモニター
- モニターごとに異なる解像度
- Windows表示倍率100%以外
- 高DPI環境
- 負の座標を持つモニター配置
- キャプチャ中に常駐ツール自身が画像へ映り込まないこと

以下の方式を主経路にはしないでください。

- Win + Shift + Sをユーザーに操作させる
- Snipping Toolのファイルを監視する
- クリップボードへ画像が入るのを待つ

このアプリだけで一連の操作を完結できることを目標とします。

## 7. VS Code拡張機能との通信

常駐Windowsアプリと自作VS Code拡張機能の間でデータを送受信します。

以下を候補として比較してください。

- Named Pipe
- localhost HTTP
- WebSocket
- 一時ファイル
- その他適切なIPC

以下の観点から推奨方式を決定してください。

- セキュリティ
- 実装難易度
- 安定性
- 双方向通信
- 画像データの転送
- 社内PCでの利用
- VS Code再起動時の復旧
- 常駐アプリ再起動時の復旧

機密情報を扱う可能性があるため、外部ネットワークを経由しないローカル通信を使用してください。

## 8. 最重要技術調査

実装前に必ず、「VS Code拡張機能からGitHub Copilot経由で画像をマルチモーダルAIへ渡し、その応答を拡張機能側で取得できるか」を現在利用可能な公式API・公式仕様で確認してください。

特に以下を確認してください。

1. VS Code Extension APIからCopilotのLanguage Model APIを利用できるか
2. そのAPIが画像入力をサポートしているか
3. VS Code Language Model APIから画像・バイナリデータを入力できるか
4. Chat Participant API等から画像を扱えるか
5. Copilot ChatのUIでは画像添付できる場合、その機能を拡張機能から利用できるか
6. 利用可能モデルごとの画像入力対応状況
7. 会社のGitHub Copilotアカウント認証をそのまま利用できるか
8. 独自APIキーなしで利用できるか
9. VS Code拡張機能からAI応答をプログラムとして受け取れるか
10. 構造化されたJSON相当の結果を安定して取得できるか

不明なAPIや存在しない機能を推測で使用しないでください。

必ず現在の公式ドキュメントを確認してください。

非公開APIのリバースエンジニアリング、Copilot通信の解析、認証情報の取得・再利用など、非公式または規約上問題になり得る方法は使用しないでください。

## 9. 画像入力

画像入力が公式に可能な場合は、キャプチャ画像からマルチモーダルAIへ直接渡す経路を主経路としてください。

Windows OCRを主経路には使用しないでください。

ただし、キャプチャ画像とOCRテキストを同時にAIへ入力することで精度向上が期待できる場合は、OCRを補助情報として使用することは許可します。

その場合も元画像を主情報とし、OCR結果だけに依存しないでください。

## 10. AIに解析させる内容

AIにはキャプチャ画像から、最低限以下を判断させてください。

- これはユーザーが行うべきタスクを含んでいるか
- タスクの短いタイトル
- タスクの詳細
- 期限
- 時刻
- 担当者
- 元画像に書かれている内容の簡潔な要約
- 判断に自信がない情報

可能であれば、以下のような構造化データとして取得してください。

    {
      "is_task": true,
      "title": "実施すべき作業の短いタイトル",
      "description": "画像から読み取った作業内容",
      "due_date": "YYYY-MM-DD",
      "due_time": null,
      "assignee": null,
      "source_summary": "画像に記載されていた内容の要約",
      "confidence": {
        "task": 0.95,
        "due_date": 0.85
      },
      "uncertain_points": []
    }

## 11. 期限の解釈

期限は特に重要な情報なので、AIに勝手に推測させすぎないでください。

キャプチャ日時をAI解析時の基準日時として渡してください。

例：

- 「明日まで」：キャプチャ日の翌日
- 「9月10日まで」：年が文脈から明確なら具体的な日付へ変換
- 「今日中」：キャプチャ当日
- 「今週中」：必要に応じて要確認情報として扱う
- 「次回会議まで」：会議日時を取得できない場合は期限不明
- 「早めにお願いします」：具体的期限として解釈しない

画像内の情報だけでは判断できない場合、due_date は null としてください。

AIの一般常識だけを根拠に期限を補完しないでください。

## 12. 元画像の保持

AI解析結果だけではなく、元キャプチャ画像を後から確認できるようにしてください。

最低限、以下を関連付けて管理できる構造にしてください。

- 元キャプチャ画像
- キャプチャ日時
- AI解析結果
- ユーザー修正後の結果
- チケットID
- チケット作成日時

AIが誤認識した場合でも、元画像を見れば内容を確認できることを重視します。

元画像をチケットへ添付できる場合は、その方式も検討してください。

ただし、チケットシステムの仕様上添付できない場合は、別の安全な保存方法を検討してください。

## 13. 確認画面

AI解析後は確認画面を表示してください。

最低限以下を表示してください。

- 元キャプチャ画像
- タイトル
- タスク内容
- 期限
- 時刻
- 担当者
- AIの信頼度
- 不確実な項目
- 自動登録までの残り時間

タイトル、内容、期限、担当者などはユーザーが編集できるようにしてください。

## 14. 自動チケット登録

確認画面を表示すると同時に、自動登録までのカウントダウンを開始してください。

例えば初期設定を30秒とします。

画面上には「27秒後に自動登録します」のように残り時間を表示してください。

ユーザーが何も操作しなかった場合は、カウントダウン終了後、現在の解析結果でチケットを自動登録してください。

チケット登録完了後は確認画面を閉じ、通常のキャプチャ待機状態へ自動的に戻してください。

毎回ユーザーが登録ボタンを押さなくても運用できることを重視します。

## 15. 確認画面での操作

以下の操作を用意してください。

- 今すぐ登録
- 編集
- 再解析
- キャンセル
- 自動登録の一時停止

ユーザーがタイトル、内容、期限などの編集を開始した場合は、自動登録カウントダウンを停止してください。

編集中の内容が勝手に登録されないようにしてください。

単にマウスカーソルが確認画面上に存在するだけではカウントダウンを停止しないでください。

入力欄へのフォーカス、実際の編集操作、自動登録停止操作など、明確なユーザー操作が行われた場合に停止してください。

編集完了後については、ユーザーが手動登録する、またはユーザー操作でカウントダウンを再開するなど、安全な操作方法を設計してください。

## 16. 自動登録時間の設定

自動登録までの時間は設定画面から変更できるようにしてください。

例えば以下を選択できるようにしてください。

- 10秒
- 30秒
- 60秒
- 120秒
- 自動登録しない

初期値は30秒程度を想定します。

## 17. 自動登録してはいけないケース

AI解析結果に重大な不確実性がある場合は、自動登録しないでください。

例えば以下です。

- is_task = false
- タイトルを生成できなかった
- タスク内容を特定できなかった
- AI解析自体が失敗した
- 画像を十分に読み取れなかった
- 重要項目についてAIが明示的に「要確認」と判断した

この場合はカウントダウンを開始せず、ユーザーの確認待ち状態にしてください。

期限が存在しない、または期限を読み取れないことだけを理由に自動登録を禁止する必要はありません。

期限なしタスクとして登録できるようにしてください。

## 18. チケット登録後

チケット作成に成功した場合は、以下の流れにしてください。

1. チケットIDを取得
2. 必要な情報を記録
3. 元画像との関連付けを保存
4. 登録完了を短時間通知
5. 確認画面を閉じる
6. キャプチャ待機状態へ戻る

完了通知は、作業を妨げないWindowsトースト通知などを検討してください。

## 19. チケット登録失敗時

チケット作成に失敗した場合は、確認画面を閉じないでください。

キャプチャ待機状態にも戻らないでください。

以下を提供してください。

- 登録失敗表示
- エラー概要
- 再試行
- 内容をコピー
- 一時保存
- キャンセル

通信エラーなど一時的な問題の場合、再試行できるようにしてください。

登録失敗したタスクが知らないうちに失われない設計にしてください。

## 20. チケット作成先

チケット作成先は現時点では固定しません。

将来的に以下へ対応できる構造にしてください。

- GitHub Issues
- Jira
- Azure DevOps
- Redmine
- 社内チケット管理システム
- Excel
- CSV
- ローカルファイル
- その他

AI解析処理とチケット登録処理を分離してください。

チケット作成先を後から変更・追加できる設計にしてください。

例えば、TicketProvider のような共通インターフェースを設け、それぞれのチケットシステム向け実装を差し替えられる構成を検討してください。

## 21. 状態管理

ツールの動作を明確にするため、状態を明示的に管理してください。

基本状態は以下を想定します。

1. 待機
2. キャプチャ中
3. AI解析中
4. 確認・自動登録待ち
5. チケット登録中
6. 登録完了
7. 待機

例外時は以下とします。

- キャプチャキャンセル：待機
- AI解析失敗：確認・再試行
- AI解析結果が要確認：確認待ち
- チケット登録失敗：確認・再試行
- ユーザーキャンセル：待機

ユーザーが何も操作せず正常に処理された場合、キャプチャ、AI解析、数十秒の確認、自動登録、待機まで自動的に進むことを目標としてください。

## 22. セキュリティ・機密情報

業務上の情報をキャプチャする可能性があります。

以下を考慮してください。

- 外部AIサービスへ勝手に送信しない
- 会社から許可されているGitHub Copilot環境のみを利用する
- キャプチャ画像を不要に外部保存しない
- 一時画像の保存場所を明確にする
- 一時画像の削除タイミングを決める
- ログへ画像内容や機密テキストを不用意に保存しない
- IPCを外部PCから利用できないようにする
- localhostを利用する場合は他プロセスからの不正利用も考慮する
- 認証情報をソースコードへ埋め込まない
- GitHub Copilotの非公開APIを利用しない

## 23. Windowsアプリの実装方式

以下の候補を比較してください。

- 案A：C# / .NET + VS Code拡張機能
- 案B：Electron + VS Code拡張機能
- 案C：Pythonデスクトップアプリ + VS Code拡張機能
- 案D：可能であればVS Code拡張機能のみ

以下の観点で比較してください。

- 常駐アプリとしての安定性
- 常に最前面表示
- タスクトレイ
- グローバルショートカット
- 範囲キャプチャ
- マルチモニター対応
- 高DPI対応
- UI作成
- 配布のしやすさ
- 管理者権限の必要性
- 社内PCへの導入容易性
- 保守性
- VS CodeとのIPC
- GitHub Copilotとの連携

Windows専用ツールで問題ありません。

## 24. 開発方針

最初から完成版を作らないでください。

技術的に不確実な部分を先に検証してください。

以下のPhaseに分けて開発してください。

### Phase 1：技術調査

現在の公式VS Code / GitHub Copilot APIについて調査してください。

特に、VS Code拡張機能からGitHub Copilotを経由して画像入力を行い、AI応答を取得できるかを公式APIだけで確認してください。

この段階ではコード量を増やさないでください。

### Phase 2：キャプチャPoC

Windows常駐アプリの最小版を作成してください。

実装内容：

- 小型ウィンドウ
- 最前面表示
- キャプチャボタン
- 範囲選択
- PNG画像取得
- 画像プレビュー

ここではAI連携しなくて構いません。

### Phase 3：IPC PoC

WindowsアプリとVS Code拡張機能を接続してください。

最初は画像ではなく、“Hello” などの文字列を送信し、Windowsアプリ、VS Code拡張機能、Windowsアプリの双方向通信を確認してください。

### Phase 4：画像転送PoC

WindowsアプリからVS Code拡張機能へキャプチャ画像1枚を渡してください。

画像が破損せず取得できることを確認してください。

### Phase 5：AI画像解析PoC

VS Code拡張機能からGitHub Copilot経由で画像をAIへ渡してください。

最初は、「この画像に何が表示されているか説明してください」程度の単純な指示で構いません。

画像そのものをAIが認識できることを確認してください。

ここが成立しない場合、完成版の実装を進めず、代替案を検討してください。

### Phase 6：タスク抽出

画像から以下を構造化して取得してください。

- タスク
- タイトル
- 内容
- 期限
- 担当者
- 信頼度
- 不確実な情報

### Phase 7：確認画面

常駐Windowsアプリへ解析結果を返してください。

以下を実装してください。

- 元画像表示
- タイトル
- 内容
- 期限
- 担当者
- 信頼度
- 編集
- 再解析
- キャンセル
- 自動登録カウントダウン

### Phase 8：自動登録制御

以下を実装してください。

- 一定時間操作なしで自動登録
- 編集開始時にタイマー停止
- 手動即時登録
- 自動登録停止
- 信頼度が低い場合の自動登録禁止
- 登録後の待機状態への自動復帰

### Phase 9：チケット登録

TicketProvider等を利用し、実際のチケット登録処理を実装してください。

### Phase 10：実運用対応

以下を整備してください。

- エラー処理
- ログ
- 設定画面
- 一時画像管理
- タスクトレイ
- グローバルショートカット
- Windows自動起動
- 配布方法
- 更新方法
- セキュリティ対策

## 25. 最初の回答で行ってほしいこと

まだ完成版コードを書かないでください。

まず現在の公式仕様を調査し、以下を回答してください。

1. この構想は公式APIだけで実現可能か
2. VS Code拡張機能からGitHub Copilotを利用できるか
3. VS Code拡張機能から画像をCopilotのAIモデルへ直接渡せるか
4. AIの応答をVS Code拡張機能側で取得できるか
5. 会社のGitHub Copilotアカウントだけで実現できるか
6. 推奨するWindowsアプリの実装技術
7. 推奨するWindowsアプリとVS Code拡張機能間のIPC
8. 推奨アーキテクチャ
9. 技術的に難しい部分・現在実現できない部分
10. 画像直接入力が不可能だった場合の代替案
11. 最初に作るべき最小PoC
12. この要求仕様について追加で決める必要がある項目

調査結果について、公式ドキュメントで確認できた事項と、推測・未確認事項を明確に分けてください。

最重要事項は、「画像を直接GitHub Copilot経由のAIへ渡し、解析結果をプログラムとして受け取れること」です。

この部分を確認できるまでは、大規模な実装を開始しないでください。