はじめに
2/5にCodex5.3とOpus4.6がリリースされて、様々な評価がされているようなので、既存の業務ワークフロー（xlsx）をどのように認識して、解釈できるか試しに指示してみました。
Anthropic
OpenAI
ちなみに現行ワークフローでも49ステップとなかなか複雑なワークフローです。
Opus4.6
指示文
HWSアサイン管理/アサイン管理ワークフロー.xlsxから現行のHWSのアサイン管理ワークフローをmd形式に出力して。ワークフローと誰が何をしているかが分かりやすくまとめて欲しい
openpyxlのインストールから、しっかりレポートを作成してくれました。
現行ワークフロー解析（Opus4.6）
HWS 現行アサイン管理ワークフロー
登場人物・システム
| 役割 | 主な責務 | 利用ツール |
|---|---|---|
| BizDev | 営業活動全般（問合せ対応〜提案書作成） | Teams / Mail / 過去提案資料 |
| エンジニア | ソリューション検討・見積もり・体制検討 | 過去見積もり |
| Planner | 営業状況・PJ状況・担当者の管理 | 営業状況 / PJ状況 / 担当者情報 |
| 部長 | PM候補選定・アサイン承認・体制確認 | アサイン体制表（エンジニア/PMの工数、PJ情報と暫定体制） |
| PM | PJ計画・体制構築・見積もり・PJ立上げ | ― |
| ZAC | 受注・PJ計画・ジョブの管理 | ジョブ / PJ計画 / メンバー実稼働工数 |
| 事業本部長 | 事業判断・投資判断・リスク判断 | ― |
ワークフロー全体像
営業フェーズ → 提案フェーズ → アサイン調整フェーズ → 見積もり・承認フェーズ → PJ立上げフェーズ → 運用フェーズ
Phase 1: 営業フェーズ
| # | アクション | 担当 |
|---|---|---|
| 1 | 問合せ / MS紹介 / AgentCamp | BizDev |
| 2 | 営業状況登録 | Planner |
| 3 | 顧客ヒアリング | BizDev |
| 4 | BANT登録 | Planner |
| 5 | 自社紹介 | BizDev |
| 6 | ディスカッション | BizDev |
事業本部長: 営業状況確認・投資判断（事業本部MTGの責務①）
Phase 2: 提案フェーズ
| # | アクション | 担当 |
|---|---|---|
| 7 | ソリューション検討 | エンジニア |
| 8 | 提案書作成 | BizDev |
| 9 | デモ作成 | エンジニア |
| 10 | 概算見積もり | エンジニア |
| 11 | 体制検討 | エンジニア |
Phase 3: アサイン調整フェーズ（PM選定）
| # | アクション | 担当 |
|---|---|---|
| 12 | HWS内所管検討 | BizDev |
| 13 | 部長・PM候補相談 | BizDev |
| 14 | PM候補検索 | 部長 |
| 15 | PM工数確認 | 部長（アサイン体制表参照） |
| 16 | PM本人状況確認 | PM（本人） |
| 17 | PM候補提示 | 部長 |
| 18 | 部長・PMへ状況説明 | BizDev |
| 19 | ZAC登録 | 部長 |
| 20 | 受注確度 / 金額登録 | ZAC |
事業本部長: 事業予実確認・事業判断（事業本部MTGの責務②）
未達の場合 → 営業強化 / 営業継続 / 生産稼働増
Phase 4: アサイン調整フェーズ（メンバー選定）
| # | アクション | 担当 |
|---|---|---|
| 21 | アサイン検討 | PM |
| 22 | メンバー工数確認 | PM（アサイン体制表参照） |
| 23 | エンジニア本人状況確認 | エンジニア（本人） |
| 24 | 体制表更新 / 資料追加 | PM（アサイン体制表） |
| 25 | アサイン検討結果確認 | 部長 |
| 26 | アサイン会で確認 | 部長（アサイン会の責務: Planner） |
| 27 | PRO/DIに適したメンバーがいるか確認 | 部長 |
| 28 | 体制FB | 部長 |
Phase 5: 見積もり・承認フェーズ
| # | アクション | 担当 |
|---|---|---|
| 29 | 体制検討（詳細） | PM |
| 30 | 見積もり作成 | PM |
| 31 | 体制利益計算表作成 | PM |
| 32 | 体制 / 粗利確認 | 部長 |
| 33 | 事業本部長承認 | PM → 事業本部長 |
| 34 | PJ計画作成 | PM |
Phase 6: PJ立上げフェーズ
| # | アクション | 担当 |
|---|---|---|
| 35 | PJ情報更新 | Planner |
| 36 | PlannerにPJ登録 | PM |
| 37 | ZACにPJ登録 | PM |
| 38 | PJ登録（ZAC側） | ZAC |
| 39 | PJ計画（ZAC側） | ZAC |
| 40 | ジョブ登録 | ZAC |
| 41 | GitHubリポジトリ申請依頼 | PM |
| 42 | PJ管理ツール選定 | PM |
| 43 | KickOff資料作成 | PM |
Phase 7: 運用フェーズ
| # | アクション | 担当 |
|---|---|---|
| 44 | PJ状況報告 | PM |
| 45 | 課題の共有・エスカレーション | 部長 |
事業本部長: リスク報告を受け事業判断（事業本部MTGの責務③）
現行ワークフローの課題
アサイン体制表（Excel）を中心とした運用に以下の課題がある:
| # | 課題 |
|---|---|
| 1 | 課題検索ができない → 結局全ページ眺める必要がある |
| 2 | 正しい情報か不明 → 情報の信頼性が担保されない |
| 3 | 案件概要 / 状況は不明 → 案件の全体像が見えない |
| 4 | 本人確認が必要 → PM/エンジニアに都度確認が発生 |
| 5 | エンジニアやPMのスキル不明 → 適切なアサインが困難 |
| 6 | PROの人員状況 不明 → 外部リソースの把握ができない |
| 7 | パートナー調達状況不明 → パートナー活用の判断ができない |
| 8 | 類似PJ / スキルの検索ができない → 過去の知見が活かせない |
指示
mermaid.jsで現行のワークフローとToBeのワークフローを表現して、違いもわかるところを教えて
現行ワークフローとTobeワークフロー比較
HWS アサイン管理ワークフロー（Mermaid図）
1. 現行ワークフロー
2. 改善ワークフロー（ToBe）
3. 現行 vs 改善 差分比較表
| フェーズ | ステップ | 現行（AsIs） | 改善（ToBe） | 改善効果 |
|---|---|---|---|---|
| Phase 1-2 | 営業・提案 | 変更なし | 変更なし | ― |
| Phase 3 | PM候補検索 | アサイン体制表（Excel）を全ページ手動閲覧 | アプリで事業部横断のPM検索。案件属性に合ったPMを検索可 | 工数減 |
| PM工数確認 | 手動で体制表を確認 | アプリでPMの工数と案件を横断確認 | 工数減 | |
| PM確定通知 | 都度口頭/メールで連絡 | Teams通知で部長が任意タイミングで確認可 | 効率化 | |
| 案件重要度判断 | 部長の経験と感覚 | アサイン評価機能で案件重要度（顧客売上規模、MS評価、セグメント、事業属性、新規性、売上）を自動評価 | 品質向上 | |
| Phase 4 | アサイン検討 | 手動でメンバー探索 | 事業部横断で案件属性に合ったエンジニアを検索可 | 工数減 |
| エンジニア本人確認 | 都度口頭で確認 | エンジニア自身がアプリで来月のアサイン状況や案件属性を確認可 | 効率化 | |
| 体制表更新 | 手動でExcel更新 | 仮PJ作成から体制表をExport | 工数減 | |
| PRO/DI確認 | 部長が手動で確認 | PROやDI、パートナー情報もアプリに集約。不要に | 効率化 | |
| Phase 5 | 体制/粗利確認 | 部長が手動で確認・判断 | 体制利益計算表の結果を入力 → アサイン評価機能で案件重要度を評価し体制と粗利の評価品質を担保 | 品質向上 |
| 見積もり作成 | Excel手作業 | 将来的にシステム化（当面はExcel取込） | 将来改善 | |
| 事業本部長承認 | PM経由で承認依頼 | 事業本部長がアプリで直接承認 | 効率化 |
4. 現行の課題と改善での解決状況
| # | 現行の課題 | 改善後 |
|---|---|---|
| 1 | 課題検索ができない → 全ページ閲覧が必要 | 解消（Clear） アプリで検索可能に |
| 2 | 正しい情報か不明 | 改善 アプリで一元管理し情報の信頼性向上 |
| 3 | 案件概要/状況が不明 | 改善 アプリに案件情報を集約 |
| 4 | 本人確認が必要 | 改善 エンジニア自身がアプリで確認可 |
| 5 | エンジニアやPMのスキル不明 | 改善 スキル情報をアプリに登録・検索可 |
| 6 | PROの人員状況が不明 | 改善 PRO情報もアプリに集約 |
| 7 | パートナー調達状況が不明 | 改善 パートナー情報もアプリに集約 |
| 8 | 類似PJ/スキルの検索ができない | 改善 案件属性・スキルでの検索が可能に |
Codex5.3
指示文
HWSアサイン管理/アサイン管理ワークフロー.xlsxから現行のHWSのアサイン管理ワークフローをmd形式に新しいファイルで出力して。ワークフローと誰が何をしているかが分かりやすくまとめて欲しい。
openpyxlがインストールされていないから、バッシュのコマンドで解析を進めていました。
xml.etree.ElementTreeは使って、シートの中身を取ってきて解析してそうです。（これはOpus4.6もやってました）
現行ワークフロー解析（Codex5.3）
現行HWSアサイン管理ワークフロー（xlsx抽出版）
対象: HWSアサイン管理/アサイン管理ワークフロー.xlsx の 現行WF シート
1. 登場ロールと主担当
| ロール | 主な担当作業 |
|---|---|
| BizDev | 問合せ対応、顧客ヒアリング、自社紹介、提案書作成、所管検討・説明 |
| エンジニア | ソリューション検討、概算見積もり、体制検討、本人状況確認 |
| Planner | 営業状況登録、BANT登録、PJ情報更新 |
| 部長 | PM候補提示、アサイン結果確認、アサイン会確認、体制/粗利確認 |
| PM | アサイン検討、体制表更新、見積もり作成、PJ計画作成、PJ状況報告 |
| ZAC | 受注確度/金額登録、PJ登録、PJ計画、ジョブ登録 |
| 事業本部長 | 投資判断、事業判断、リスク報告を受けた判断 |
2. ワークフロー（時系列）
フェーズA: 営業・初期提案
- BizDev: 問合せ / MS紹介 / AgentCamp
- Planner: 営業状況登録
- BizDev: 顧客ヒアリング
- Planner: BANT登録
- BizDev: 自社紹介
- BizDev: ディスカッション
- エンジニア: ソリューション検討
- BizDev: 提案書作成（必要に応じてデモ作成）
- エンジニア: 概算見積もり
- エンジニア: 体制検討
フェーズB: PM選定・受注確度更新
- BizDev: HWS内所管検討
- BizDev: 部長・PM候補相談
- 部長: PM候補検索
- 部長: PM工数確認
- PM: 本人状況確認
- 部長: PM候補提示
- BizDev: 部長・PMへ状況説明
- 部長: ZAC登録
- ZAC: 受注確度 / 金額登録
フェーズC: メンバーアサイン確定
- PM: アサイン検討
- PM: メンバー工数確認
- エンジニア: 本人状況確認
- PM: 体制表更新 / 資料追加
- 部長: アサイン検討結果確認
- 部長: アサイン会で確認
- 部長: PRO/DIに適したメンバーがいるか確認
- 部長: 体制FB
フェーズD: 見積・承認・PJ立上げ
- PM: 体制検討（詳細化）
- PM: 見積もり作成
- PM: 体制利益計算表作成
- 部長: 体制 / 粗利確認
- 事業本部長: 承認
- PM: PJ計画作成
- Planner: PJ情報更新
- PM: PlannerにPJ登録
- PM: ZACにPJ登録
- ZAC: PJ登録 / PJ計画 / ジョブ登録
- PM: GitHubリポジトリ申請依頼
- PM: PJ管理ツール選定
- PM: KickOff資料作成
フェーズE: 実行・モニタリング
- PM: PJ状況報告
- 部長: 課題の共有・エスカレーション
- 事業本部長: リスク報告を受け事業判断
3. 誰が何をしているか（ロール別サマリ）
BizDev
- 案件の入口から提案初動までを主導。
- PM選定時は、所管検討と部長/PMへの状況説明を担当。
エンジニア
- 技術観点の提案具体化（ソリューション・見積・体制検討）を担当。
- アサイン時は本人状況確認に関与。
Planner
- 営業ステータスと案件情報の台帳更新を担当（営業状況/BANT/PJ情報）。
部長
- PM候補選定とアサイン判断のゲート役。
- アサイン会運営、体制妥当性・粗利の最終確認を担当。
PM
- 候補確認後の体制構築を実行責任として担当。
- 見積、PJ計画、各種登録、KickOff準備、進行報告を一気通貫で担当。
ZAC
- 受注確度・金額、PJ・ジョブ情報の基幹登録を担当。
事業本部長
- 事業本部MTGで投資/事業判断を実施し、リスク報告に対する最終判断を担当。
4. 補足（現行WF上の明示課題）
現行WF には、以下の運用課題が明示されている。
- 課題検索が難しく、全体を目視確認する運用になりやすい
- 案件概要・状況の把握がしづらい
- スキルや人員状況（エンジニア/PM/PRO/パートナー）の横断把握が難しい
- 類似PJやスキル検索がしづらく、過去知見を再利用しにくい
指示
mermaid.jsで現行のワークフローとToBeのワークフローを表現して、違いもわかるところを教えて。新しいmdファイルを作成して
現行ワークフローとTobeワークフロー比較
HWSアサイン管理ワークフロー（現行 / ToBe）
対象: HWSアサイン管理/アサイン管理ワークフロー.xlsx（現行WF / アサイン改善WF）
1. 現行ワークフロー（As-Is）
2. ToBeワークフロー（改善）
3. 現行とToBeの違い（要点）
| 領域 | 現行 | ToBe | 分かる違い |
|---|---|---|---|
| PM候補探索 | 手動（体制表中心） | アプリで事業部横断検索 | 探索工数の削減、候補精度向上 |
| PM工数確認 | 手動確認 | 工数/案件を横断確認 | 確認スピード向上 |
| PM確定連絡 | 個別連絡 | Teams通知 | 連絡漏れ・待ち時間の削減 |
| メンバー探索 | 手動 | 案件属性で検索 | アサイン品質向上 |
| エンジニア確認 | 都度確認 | 本人がアプリ確認 | 調整往復の削減 |
| 体制表更新 | 手更新 | 仮PJからExport | 転記工数とミス削減 |
| PRO/DI/パートナー情報 | 分散しやすい | アプリ集約 | 意思決定の前提情報を統一 |
| 体制/粗利評価 | 人依存が大きい | 評価機能で補助 | 判断品質の標準化 |
| 見積プロセス | Excel中心 | 将来システム化（初期はExcel取込） | 段階的に自動化 |
| 事業本部長承認 | PM経由 | アプリ上で直接承認 | 承認リードタイム短縮 |
4. 差分のまとめ
- フローの大枠（営業→提案→アサイン→承認→立上げ→運用）は同じ。
- 差分の中心は、
PM/メンバー探索、工数確認、通知、評価、承認のデジタル化。 - 期待効果は
工数減、効率化、品質向上の3点に集約される。
評価をOpus4.6とCodex5.3にしてもらった
Opus4.6評価
指示
codex5.3とopus4.6で作成したmdファイルをそれぞれ違いとどちらが優れているか評価してmdファイルを作成して
評価
Codex 5.3 vs Claude Opus 4.6 出力比較・評価
対象ファイル
| モデル | テキスト版WF | Mermaid版WF |
|---|---|---|
| Codex 5.3 |
現行アサイン管理ワークフロー_xlsx抽出版_codex5.3.md（106行） |
現行ToBeアサイン管理ワークフロー_mermaid_codex5.3.md（200行） |
| Opus 4.6 |
現行アサイン管理ワークフロー_claudeOpus4.6.md（140行） |
アサイン管理ワークフロー_mermaid_claudeOpus4.6.md（265行） |
1. テキスト版WFの比較
構成の違い
| 観点 | Codex 5.3 | Opus 4.6 |
|---|---|---|
| フェーズ分割 | 5フェーズ（A〜E） | 7フェーズ（Phase 1〜7） |
| ロール一覧 | シンプルな2列表（ロール / 主な担当作業） | 3列表（役割 / 主な責務 / 利用ツール） |
| ステップ記法 | 番号付きリスト（1. BizDev: 問合せ...） |
番号付きテーブル（` |
| ロール別サマリ | あり（各ロールの責務を文章で解説） | なし |
| 事業本部長の判断 | フェーズEの最後に1行 | 各フェーズの末尾に引用ブロックで記載（①②③） |
| 課題セクション | 簡潔に4項目を要約 | 8項目を個別に表で整理 |
| 全体像の図 | なし | テキストの矢印フロー（営業 → 提案 → ...） |
評価
| 評価軸 | Codex 5.3 | Opus 4.6 | 優位 |
|---|---|---|---|
| 情報の網羅性 | 課題の記載が4項目に要約されており、情報が一部省略されている | Excel原本の8項目をすべて個別に記載。利用ツールもロール表に含む | Opus 4.6 |
| フェーズ粒度 | 5フェーズ。「見積・承認・立上げ」が1つにまとまっており粗い | 7フェーズ。PM選定/メンバー選定/見積・承認/PJ立上げが分離されており粒度が適切 | Opus 4.6 |
| 可読性 | 番号付きリストでシンプル。文章でのロール別サマリが読みやすい | テーブル形式で一覧性が高い。ただしロール別サマリがない | Codex 5.3 |
| ロール理解のしやすさ | ロール別サマリがあり、各人が何をしているか一目瞭然 | テーブル内に担当列があるが、ロール横断のサマリがない | Codex 5.3 |
| 事業本部長の扱い | フローの最後に1行だけ。事業本部MTGの構造が不明確 | 各フェーズに事業本部MTGの責務①②③を明示 | Opus 4.6 |
| 簡潔さ | 106行でコンパクト | 140行でやや冗長 | Codex 5.3 |
2. Mermaid版WFの比較
構成の違い
| 観点 | Codex 5.3 | Opus 4.6 |
|---|---|---|
| 図の数 | 現行WF 1つ + ToBe WF 1つ | 現行WF 1つ + ToBe WF 1つ |
| ノードの表記 |
[アクション名\n担当者]（担当者が下に表示） |
["絵文字 担当者: アクション名"]（色絵文字+担当者が先） |
| 改善ポイントの表現 | 改善ノードを別ノードとして分岐（TB3-->TB3X） |
改善内容を既存ノード内に🆕で併記（C3_new） |
| スタイリング |
classDef improvement で改善ノードを緑背景 |
個別ノードに style で緑背景 + 太枠 |
| subgraph名 | 短い（A[営業・提案]） |
詳細（Phase1["Phase 1: 営業フェーズ"]） |
| 事業本部長 | 現行WFのフロー内に含む | 別subgraphで判断ポイントを分離、点線で接続 |
| データ資産 | なし | ToBe図に「データ資産」subgraphあり |
| 差分比較表 | あり（10行の簡潔な表） | あり（11行+課題解決状況8行の詳細な表） |
| 差分まとめ | あり（箇条書き3行で要約） | なし（表で完結） |
評価
| 評価軸 | Codex 5.3 | Opus 4.6 | 優位 |
|---|---|---|---|
| Mermaid記法の正確性 | 正しい。classDefの使い方が適切 |
正しい。ただし日本語subgraph名にマルチバイト文字を使っており一部レンダラーで問題の可能性あり | Codex 5.3 |
| 改善ポイントの視認性 | 改善ノードが分岐で表示 → フローが複雑になるが「何が変わったか」が一目瞭然 | 既存ノードに改善内容を埋め込み → フロー構造は維持されるが、ノードテキストが長くなる | 引き分け（アプローチが異なる） |
| 図の見やすさ | ノードテキストが短くシンプル。図がコンパクト | 絵文字+担当者名で情報量が多い。フェーズごとの色分けが視覚的に良い | Opus 4.6 |
| ToBe図の情報量 | 改善ポイントのみ強調、データ資産の記載なし | データ資産subgraph、Teams通知ノードなどExcel原本の情報を網羅 | Opus 4.6 |
| 差分比較の充実度 | 10行の表+3行の要約。簡潔で分かりやすい | 11行の詳細表+8行の課題解決対応表。情報量が多い | Opus 4.6（網羅性）/ Codex 5.3（簡潔さ） |
| レンダリング互換性 | ID名が英数字のみで互換性が高い | ID名に_、subgraph名に日本語を使用。大半のレンダラーで動作するが互換性はやや劣る |
Codex 5.3 |
| フロー構造の忠実性 | 現行・ToBeで同じフロー構造を維持し、改善は分岐ノードで表現 | 現行・ToBeで改善ノードに差し替え。フロー構造の差異が明確 | 引き分け |
3. 総合評価
スコア一覧（5点満点）
| 評価軸 | Codex 5.3 | Opus 4.6 |
|---|---|---|
| 情報の網羅性 | 3.5 | 4.5 |
| Excel原本への忠実性 | 3.5 | 4.5 |
| 可読性・簡潔さ | 4.5 | 3.5 |
| フェーズ分割の適切さ | 3.0 | 4.5 |
| Mermaid図の品質 | 4.0 | 4.0 |
| 改善ポイントの表現 | 3.5 | 4.0 |
| 差分の分かりやすさ | 4.0 | 4.0 |
| レンダリング互換性 | 4.5 | 3.5 |
| ロール理解のしやすさ | 4.5 | 3.5 |
| 実務での活用しやすさ | 4.0 | 4.0 |
| 合計 | 39.0 | 40.0 |
総合判定
僅差でOpus 4.6が優位だが、それぞれ異なる強みがある。
Codex 5.3 の強み
- 簡潔さ: 無駄がなくコンパクト。読み手の負荷が低い
- ロール別サマリ: 「誰が何をしているか」の文章説明があり、初見でも理解しやすい
- Mermaid互換性: ノードID・subgraph名が英数字中心で、あらゆるレンダラーで安定して動作
- 改善の表現方法: 分岐ノードで「何が追加されたか」が構造的に明確
Opus 4.6 の強み
- 情報の網羅性: Excel原本の情報（課題8項目、利用ツール、データ資産、事業本部MTG責務①②③）を漏れなく反映
- フェーズ粒度: PM選定/メンバー選定/見積もり・承認/PJ立上げを分離し、実務のフローに忠実
- 視覚表現: 色絵文字によるロール識別、フェーズごとの背景色、事業本部長判断の点線分離
- 課題解決の追跡: 現行8課題がToBeでどう解決されるかの対応表がある
使い分けの推奨
| 用途 | 推奨モデル | 理由 |
|---|---|---|
| 経営層への報告 | Codex 5.3 | 簡潔で要点が伝わりやすい |
| 開発チームへの仕様共有 | Opus 4.6 | 情報が網羅的で、実装時の参照資料として有用 |
| ステークホルダーへの改善提案 | Opus 4.6 | 課題→解決の対応が明確で説得力がある |
| 社内Wiki・ナレッジベース | Codex 5.3 | コンパクトでメンテしやすい |
評価結果サマリ
総合スコア
Codex 5.3（39.0点） vs Opus 4.6（40.0点）
→ 僅差で Opus 4.6 が優位
各モデルの強み
| Codex 5.3 | Opus 4.6 |
|---|---|
| 簡潔でコンパクト（106行 vs 140行） | 情報の網羅性（課題8項目、データ資産、事業本部MTG責務を完全網羅） |
| ロール別サマリで「誰が何を」が文章で分かりやすい | フェーズ粒度が適切（PM選定 / メンバー選定を分離） |
| Mermaid記法の互換性が高い（英数字ID中心） | 視覚表現が豊か（色絵文字、背景色、点線接続） |
| 改善点を分岐ノードで構造的に表現 | 課題 → 解決の対応表がある |
使い分け
- 経営層報告・社内Wiki → Codex 5.3（簡潔さ重視）
- 開発仕様・改善提案 → Opus 4.6（網羅性・説得力重視）
Codex5.3評価
指示
codex5.3とopus4.6で作成したmdファイルをそれぞれ違いとどちらが優れているか評価してmdファイルを作成して
評価
codex5.3 と opus4.6 の成果物比較評価
対象ファイル:
- 現行説明（opus4.6）:
HWSアサイン管理/現行アサイン管理ワークフロー_claudeOpus4.6.md - 現行説明（codex5.3）:
HWSアサイン管理/現行アサイン管理ワークフロー_xlsx抽出版_codex5.3.md - Mermaid（opus4.6）:
HWSアサイン管理/アサイン管理ワークフロー_mermaid_claudeOpus4.6.md - Mermaid（codex5.3）:
HWSアサイン管理/現行ToBeアサイン管理ワークフロー_mermaid_codex5.3.md
1. 評価基準
5段階評価（5が最良）
- 正確性: 元Excelの内容を過不足なく反映しているか
- 網羅性: ロール・工程・課題・改善点まで含められているか
- 可読性: 読みやすさ、構造の分かりやすさ
- 実務有用性: 説明資料としてそのまま使えるか
- 保守性: 更新のしやすさ、記述のシンプルさ
2. 現行説明mdの比較
| 観点 | opus4.6 | codex5.3 | コメント |
|---|---|---|---|
| 正確性 | 4.5 | 4.5 | 主要工程はどちらも一致 |
| 網羅性 | 5.0 | 4.0 | opus4.6は課題8件を明示、codex5.3は要約中心 |
| 可読性 | 4.5 | 4.5 | opus4.6は表形式、codex5.3はフェーズ文章で読みやすい |
| 実務有用性 | 5.0 | 4.0 | 役割・工程・課題の粒度はopus4.6が高い |
| 保守性 | 4.0 | 5.0 | codex5.3の方が短く編集しやすい |
| 総合 | 4.6 | 4.4 | 現行説明は opus4.6 が優位 |
3. Mermaid mdの比較
| 観点 | opus4.6 | codex5.3 | コメント |
|---|---|---|---|
| 正確性 | 4.5 | 4.5 | フロー骨格は同等 |
| 網羅性 | 5.0 | 4.2 | opus4.6は判断ポイント、課題解決表、データ資産まで包含 |
| 可読性 | 4.2 | 4.8 | codex5.3は図がシンプルで追いやすい |
| 実務有用性 | 5.0 | 4.3 | opus4.6は説明材料（差分表・解決状況）が厚い |
| 保守性 | 3.8 | 4.8 | codex5.3は行数が少なく改修しやすい |
| 総合 | 4.5 | 4.5 | 用途で優劣が分かれる（実務資料=opus4.6、運用更新=codex5.3） |
補足:
- 行数比較: opus4.6（264行） / codex5.3（199行）
- opus4.6は図の装飾・補足表が多く、説明力が高い
- codex5.3は図の主線が短く、レビューや更新がしやすい
4. 差分の要点
現行説明md
- opus4.6: 45ステップを表で厳密に管理し、課題8件を明示
- codex5.3: 5フェーズに要約し、ロール別サマリを重視
Mermaid md
- opus4.6: 図に加えて「差分比較表」「課題の解決状況」まで1ファイルに統合
- codex5.3: 図を中心にコンパクト化し、改善ノードを
classDefで強調
5. 最終判定（どちらが優れているか）
- 総合的には opus4.6 がやや優位（網羅性と説明力が高く、意思決定資料に向く）
- ただし、継続運用・更新効率を重視するなら codex5.3 が優位（簡潔で保守しやすい）
推奨:
- 社内説明・合意形成用の正本: opus4.6ベース
- 日常運用・更新用の作業版: codex5.3ベース
- codex5.3 と opus4.6 の成果物を2系統（現行説明md / mermaid md）で比較
- 評価軸（正確性・網羅性・可読性・実務有用性・保守性）で採点
- 差分の要点整理
- どちらが優れているかの最終判定（用途別の推奨つき）
結論は、総合は opus4.6 やや優位、運用更新性は codex5.3 優位です。
人の所感
Opus4.6の方が、As-Isのワークフロー49ステップをちゃんと出力できていて、codex5.3の方は43ステップと何かが落ちているみたいです。
LLM自身の評価もopus4.6がやや優位と出ていますが、可読性とかの前に正しく情報を認識できることが大事だと思うので、xlsxのワークフロー読み取りに関してはOpus4.6が良いのかなと言う印象です。
ただ公式もコーディングのサポートがCodex5.3は強くなったと言う話だったので、あくまでもこのタスクに関してはこのような結果が出ました。
Discussion