Codex appでAIからプロジェクト管理ツール「Redmine」を操作する方法(2)議事録からチケットを自動起票する

前回の記事 では、Codex app から AI で Redmine を操作するための設定と、基本的な動作確認までを行いました。

Redmineは、タスクや課題をチケットで管理できるオープンソースのプロジェクト管理ツールで、担当者や期日を整理しやすいため、議事録の行動計画を起票する用途とも相性がよいです。

今回はその続きとして、議事録の行動計画を読み取り、担当者や期日を補いながら Redmine のチケットとして起票する流れを紹介します。

題材は「既存販売管理システムのバージョンアップ」です。業務内容や議事録は架空ですが、実際の運用に近い形でトラッカーやカスタムフィールドを用意し、議事録からどのようにチケット化できるかがイメージしやすい例にしています。

本記事は、(1)設定・動作確認編と、(2)議事録からチケットを自動起票する、の2本だてです。

• （前回記事）「Codex appでAIからプロジェクト管理ツール「Redmine」を操作する方法(1)設定・動作確認編」
• （本記事）「Codex appでAIからプロジェクト管理ツール「Redmine」を操作する方法(2)議事録からチケットを自動起票する」

目次

• 環境
• 安全・確実に活用していただくために
• 今回の題材
• 今回の議事録と起票内容
• 起票のために用意するもの
  • 1. AGENTS.md を用意する
  • 2. メンバー情報とトラッカー情報を補助ファイルに保存する
• 議事録から起票する
• 作成されたチケットを確認する
• 補助情報を用意する理由
• 実務で使うときに考えたいこと
• まとめ

環境

今回の環境は以下の通りです。

• macOS
• Codex app
• Redmine
• MCPサーバー: runekaagaard/mcp-redmine
• 利用モデル: gpt-5.4（reasoning: medium）

Redmine 用 MCP サーバーの導入や Codex app への設定は、前回の記事で紹介した内容を前提にします。まだ設定や基本操作の確認が済んでいない場合は、先に 前回の記事 を確認してください。

安全・確実に活用していただくために

今回利用する MCP サーバーは、Redmine の REST API で提供されている各機能が実行可能です。便利な反面、Read Only モードや OAuth のような細かな権限制御を前提にした構成ではありません。

まずは検証用のプロジェクトやテスト環境で試すのがおすすめです。あわせて、最低限の権限を付与した専用ユーザーを用意し、そのユーザーで接続する形にしておくと安心です。

また、今回はシステム管理者権限を持たないロールの API キーを使っています。この場合、トラッカーに紐づくカスタムフィールドの情報を API 経由で十分に取得できないことがあります。そのため、Codex app に渡す AGENTS.md で、プロジェクト固有の前提を補っています。

今回の題材

今回の Redmine プロジェクトは、社内で利用している販売管理システムを Ver.7 から Ver.8 へ更新する想定です。会計連携アドオンの確認、データ移行リハーサル、受け入れテスト準備といった作業をチケットで管理します。

今回はトラッカーを 2 つ作成します。

1. 改修・設定

システム本体の設定変更、アドオン修正、外部連携の差分対応を管理するトラッカーです。カスタムフィールドとして 関連システム（文字列形式）を使用します。

2. テスト・移行

データ移行、検証、操作確認、リリース準備を管理するトラッカーです。カスタムフィールドとして 対象環境（リスト形式：検証, 本番, 両方）を使用します。

今回の議事録と起票内容

今回のデモでは、議事録ファイルを minutes.md という名前で配置します。議事録には次の 3 つの行動計画が記載されており、これらを一括で起票します。

• 会計連携アドオンのVer.8互換性確認（担当: 赤田、期日: 2026-03-25）
• 顧客・受注データ移行リハーサル実施（担当: 鈴木、期日: 2026-03-27）
• 受注入力UAT手順書の更新と営業部レビュー依頼（担当: 田中、期日: 2026-03-27）

# 議事タイトル
販売管理システムVer.8更新 第1回定例会議

# 開催日時
2026年3月23日（月） 14:00 - 14:40

# 出席者
* 赤田（情シスPM・更新責任者）
* 鈴木（社内SE：移行・基盤担当）
* 加藤（ベンダー窓口：改修・設定担当）
* 田中（業務部門窓口：受け入れテスト担当）

# 会議の目的
販売管理システムVer.8への更新に向けて、影響範囲の確認、今週中に着手すべき検証項目の整理、および各担当の行動計画を確定する。

# 議題と議論

## 議題1：会計連携アドオンの互換性確認
### 発言内容の要約
販売管理システム本体の更新自体は可能と見込まれる一方、会計連携アドオンの対応状況が不明確であり、先にベンダー確認と差分整理を行う必要がある。

#### 発言内容
* **更新対象の整理（赤田）**：今回の更新対象は販売管理システム本体のVer.7からVer.8への更新であり、特に会計連携と帳票出力まわりを重点確認したいと説明した。
* **ベンダー情報の共有（加藤）**：アドオン提供元の公開情報ではVer.8対応予定の記載はあるものの、現行利用中のカスタム設定を含めてそのまま動作するかは確認が必要と報告した。
* **影響範囲の確認（田中）**：会計連携が止まると月次締め処理へ影響するため、他の論点よりも優先して結論を出してほしいとの要望があった。
* **対応方針の決定（赤田）**：ベンダーへ対応版の有無、設定差分、既知制限を確認し、合わせて現行設定との差分を一覧化することを自分で担当するとした。

### 決定事項
* 会計連携アドオンを最優先確認事項とする。
* ベンダー確認と現行設定差分の整理を同時に進める。

### 行動計画
* 会計連携アドオンのVer.8互換性確認（担当：赤田、期日：3月25日）

---

## 議題2：データ移行リハーサルと営業部向けUAT準備
### 発言内容の要約
顧客データと受注データの移行は本番切替の成否に直結するため、検証環境でリハーサルを実施し、所要時間とエラー傾向を事前に把握する方針となった。あわせて、Ver.8で変更のある受注入力画面については、営業部向けのUAT準備を先行して進めることになった。

#### 発言内容
* **現状報告（鈴木）**：検証環境へのVer.8適用は今週前半に実施できる見込みであり、その後すぐに移行リハーサルへ入れると説明した。
* **対象データの確認（田中）**：営業部で最近登録した取引先や、分納を含む受注データが移行確認の観点として重要であると共有した。
* **確認ポイントの整理（加藤・鈴木）**：加藤より、移行結果の件数一致だけでなく、コード変換やステータスの引き継ぎも確認項目に入れるべきと提案。鈴木が、処理時間とエラーログの取得も行うと応じた。
* **画面差分の共有（加藤）**：受注入力画面では検索条件の初期表示や明細入力補助の挙動が一部変わるため、旧版の手順書では説明不足になると報告した。
* **業務側の懸念（田中）**：営業部のキーユーザーは月末に向けて忙しくなるため、確認観点を絞った手順書でないとレビューが進まない可能性があると述べた。
* **重点シナリオの整理（赤田・田中）**：新規受注、値引きあり受注、分納受注、受注取消の4シナリオを重点確認対象とすることで合意した。
* **依頼方法の決定（田中）**：手順書を更新したうえで、営業部キーユーザーへレビュー依頼メールを送付し、検証環境での確認日程候補も合わせて提示するとした。
* **進め方の決定（赤田）**：検証環境で本番相当データを使ったリハーサルを1回実施し、所要時間、エラー件数、手戻りポイントを記録することと、UAT準備はその結果を踏まえて営業部レビューまで進めることを指示した。

### 決定事項
* 顧客・受注データを対象に、検証環境で移行リハーサルを実施する。
* 件数一致だけでなく、業務上重要なデータ項目の整合性も確認する。
* UAT手順書はVer.8の画面差分を反映して更新し、営業部へ事前レビューを依頼する。

### 行動計画
* 顧客・受注データ移行リハーサル実施（担当：鈴木、期日：3月27日）
* 受注入力UAT手順書の更新と営業部レビュー依頼（担当：田中、期日：3月27日）

# 報告など、そのほかの事項
* 本番切替候補日は2026年4月5日（日）で仮置きし、移行リハーサル結果を見て最終判断する。
* 帳票レイアウト修正の要否については、会計連携アドオンの確認結果と合わせて次回会議で判断する。

# 次回の会議の予定
* 日時：2026年3月30日（月） 14:00 - 14:45
* 議題：
  1. 会計連携アドオン確認結果と帳票レイアウト修正要否の確認
  2. データ移行リハーサル結果と営業部向けUAT準備状況の共有

起票のために用意するもの

1. AGENTS.md を用意する

Codex app にプロジェクト固有の情報を伝えるため、作業ディレクトリに AGENTS.md を置きます。
なお、プロジェクトIDは環境にあわせて適宜修正してください。

# 概要
Codex app から Redmine に起票する際に必要な情報を記載している。

# プロジェクト情報
- プロジェクト名: 既存販売管理システムバージョンアップ
- ID: 35

## ユーザー情報
redmine_members.json


## トラッカー情報
redmine_trackers.json
カスタムフィールドについての補足
- "改修・設定"トラッカー
 名称:関連システム
 形式:文字列
- "テスト・移行"トラッカー
 名称:対象環境
 形式:リスト
 値:検証,本番,両方

今回はシステム管理者権限を使っていないため、カスタムフィールドの定義を AGENTS.md 側でも補足しています。こうしておくと、関連システム や 対象環境 をチケット作成時に埋めやすくなります。

2. メンバー情報とトラッカー情報を補助ファイルに保存する

担当者やトラッカーの情報は、先に補助ファイルとして用意しておきます。今回の例では、次のようなプロンプトで作成します。

> プロジェクトに参加しているメンバーの情報をredmine_members.jsonに保存してください。

> ２つのトラッカー"改修・設定", "テスト・移行"の情報をredmine_trackers.jsonに保存してください。

redmine_members.json は担当者候補の補助データ、redmine_trackers.json はトラッカー名や項目の補助データとして使うイメージです。

Codex app で `redmine_members.json` と `redmine_trackers.json` の作成を指示

プロンプトと保存完了の結果が両方見える構図にしてください。

議事録から起票する

準備ができたら、minutes.md の行動計画を Redmine のチケットとして起票します。今回使ったプロンプトは次の通りです。

> `minutes.md` の行動計画を Redmine のチケットとして起票してください。

Codex app は議事録の行動計画を読み取り、担当者、期日、トラッカー、必要に応じてカスタムフィールドを補いながら Redmine に登録していきます。

Codex app に起票プロンプトを入力し、チケット作成の処理が進んでいる

今回の議事録であれば、次の 3 件が作成されました。

作成されたチケットを確認する

Codex app で処理が終わったら、Redmine 側で結果を確認します。担当者、期日、トラッカーに加えて、カスタムフィールドまで意図どおり入っているかを見るのがポイントです。

チケット一覧画面で、今回作成された 3件のチケットが並んでいる

作成されたチケットの詳細画面

補助情報を用意する理由

今回のような起票では、単に議事録を渡すだけでもある程度は動くと思います。ただし、実務で使うためには、プロジェクト固有の前提を一緒に渡した方が迅速かつ安定して動作します。

• redmine_members.json があると、担当者情報を都度検索する必要がない
• redmine_trackers.json があると、どのトラッカーを使うべきかを都度検索する必要がない
• AGENTS.md にカスタムフィールドの情報を書いておくと、API だけでは不足する情報を補える

特に、今回のようにシステム管理者権限を使っていない場合は、AI が見えている情報だけで完全に判断するのが難しい場面があります。そうした不足分を、ローカルの補助ファイルで埋めるイメージです。

実務で使うときに考えたいこと

今回のデモでは、議事録の行動計画から新規チケットを起票するところまでを扱いました。実運用では、さらに次のような論点も出てきます。

• すでに起票済みのチケットとの重複をどう防ぐか
• 新規作成ではなく既存チケットの更新に切り替える条件をどう決めるか
• 誤って作成したチケットの取り消しや整理をどう行うか

AI に任せる範囲を広げるほど便利になりますが、その分だけ確認手順も重要になります。まずは検証用プロジェクトで、今回のような「議事録から数件を起票する」小さな流れから試すと扱いやすいと思います。

まとめ

Codex app と Redmine 用 MCP サーバーを組み合わせると、議事録に書かれた行動計画を、担当者や期日、トラッカー、必要に応じたカスタムフィールドを補いながら Redmine のチケットとして起票できます。今回の例では、3 件の行動計画を実務に近い形で登録できました。トラッカーの用途やカスタムフィールドの定義をあらかじめ整理し、AGENTS.md や補助ファイルで AI に渡しておくと、より安定して起票しやすくなります。