管理コンソールの「インサイト」では、チームが ChatGPT Work と Codex を何に使い、どこでクレジットを消費しているかを把握できます。ワークスペースの概要でカテゴリを開くと、そのカテゴリのタスクと利用状況を確認できます。結果を比較する前に、各ビューに表示されている対象範囲を確認してください。
これらのビューを使って、担当者とともに評価するワークフローを選びます。利用状況や支出をチームの記録と照らし合わせ、作業の手間が減っているか、品質基準を満たしているか、より良い成果につながっているかを確認します。
分析ビュー
管理コンソールには、ChatGPT Work と Codex の分析機能があります。「利用状況」にはアクティビティと消費量が表示されます。「インサイト」では、利用状況がカテゴリとタスクに分類されます。エンジニアリング業務については、「コードレビュー」でレビューの実施状況と指摘事項を確認できます。
トークンについて確認する場合は、「利用状況」で確認できるトークンの指標を使います。メッセージの割合、クレジットの割合、トークンの割合は、それぞれ異なるものを表します。結果を比較したり共有したりする際は、これらのラベルをそのまま使ってください。
「インサイト」へのアクセス
管理コンソールでワークスペースを選択し、 分析 > インサイトを開きます。そのワークスペースの分析へのアクセス権が必要です。表示されるビューやデータは、権限と有効になっている機能によって異なります。
結果を見る前に、ワークスペース、日付範囲、利用可能なフィルターを確認してください。アクティビティを比較する際は、これらの条件を揃えます。「インサイト」で確認できる履歴は、分類が開始された時点以降のものに限られます。
ユースケースとタスク
「概要」では、「ユースケース / タスク」の切り替えを使って、大まかなカテゴリとより具体的なアクティビティを切り替えられます。「ユースケース」タブでカテゴリを展開すると、そのカテゴリのタスクを確認できます。
グラフでユースケースまたはタスクを選択すると、詳細が開きます。上位 10 件以外も含めてカテゴリやタスクを比較するには、「ユースケース」テーブルを使います。
カテゴリには複数のワークフローが含まれる場合があります。単一の業務プロセスとして扱う前に、そのカテゴリのタスクを確認してください。未分類のアクティビティがある場合は、結果を説明する際にその制約を明記します。
メッセージ、クレジット、アクティブユーザー
各カテゴリやタスクを把握するには、テーブルの「メッセージ」「クレジット」「アクティブユーザー」を併せて確認します。サンプリングに関する通知が表示されている場合、表示される件数はサンプリングされたアクティビティを反映しています。この数値を比例計算で拡大して、ワークスペース全体のアクティビティを推定しないでください。
メッセージ には、カテゴリまたはタスクに関連するメッセージ数が表示されます。メッセージ数からは、チームが完了した作業量はわかりません。
クレジットの割合 には、カテゴリまたはタスクがクレジット消費量に占める割合が表示されます。「クレジット」や「メッセージ」と併せて確認し、どこに消費が集中しているかを把握します。
アクティブユーザー には、カテゴリまたはタスクを利用している人数が表示されます。「メッセージ」と併せて確認し、カテゴリの利用人数とアクティビティの量を比較します。
あるカテゴリがクレジットの大きな割合を占めている場合は、そのタスク、モデル、設定を確認してください。作業がより複雑であったり、選択したモデルが異なったりすることが、そのカテゴリのクレジット使用量の理由かもしれません。その消費に見合う価値があるかを判断する前に、チームが達成した成果を確認します。
あるカテゴリのアクティブユーザーが少ない場合は、そのユーザーに利用方法や困っている点を尋ねてください。共有する価値のあるワークフローを持っているかもしれませんし、追加のサポートが必要なのかもしれません。
カテゴリの詳細
カテゴリの詳細を開くと、右側のドロワーでタスクと利用状況の内訳を確認できます。
カテゴリ内のタスクと、それぞれが使用したクレジットを確認します。モデル別・推論別・速度別の内訳には、選択したカテゴリまたはタスクの中で、各選択肢が占めるクレジットの割合が表示されます。消費量に変化があった場合は、作業内容やこれらの設定に変更があったかをチームに確認してください。
カテゴリやタスクのプラグインおよびスキルの呼び出し回数を確認できる場合は、それらも確認します。この回数には、選択した日付範囲とフィルターに該当する ChatGPT Work と Codex のアクティビティが含まれます。呼び出し回数は、メッセージ数や完了したタスク数とは異なります。
調査結果を共有する際は、推定値には推定値であることを明記してください。プラグインとスキルへのクレジットの割り当ては重複する場合があるため、それぞれのビューの数値を足し合わせて総投資額を計算しないでください。クレジットの解釈や請求への影響について詳しくは、ChatGPT Work の利用状況とコストをご覧ください。
コードレビュー
エンジニアリング業務を評価する場合は、 コードレビュー を開き、ワークスペースで確認できるレビューの指標を参照します。
- レビュー済み PR には、Pull Request のレビュー実施状況が表示されます。レビュー済みの Pull Request が、必ずしもマージやデプロイされているとは限りません。
- 検出された問題 には、それらのレビューでの指摘事項が表示されます。どの指摘が役立ち、対応されたかをレビュー担当者に確認してください。
- 優先度別の問題、リアクション、リアクションの感情傾向 は、指摘事項やそれに対する人々の反応を理解するための補足情報になります。
件数がゼロの場合、アクティビティがなかった可能性も、レポートに欠落がある可能性もあります。件数を解釈する前に、日付範囲と、対象のレビューが含まれているかを確認してください。
価値の評価
チームが ChatGPT Work または Codex で使用しているワークフローを選びます。改善したい成果とその測定方法について、業務責任者と合意してください。「インサイト」を、顧客企業の調査資料、在庫計画、Pull Request などのチームの記録と併せて確認します。評価には、実際に業務を行っている人にも参加してもらいます。
集計期間を揃え、サンプリングに関する通知があれば確認してください。カテゴリには複数のワークフローが含まれる場合があり、アクティビティの件数は完了した作業量を表すものではありません。以下の例では、利用データとワークフローから得られる根拠の両方を使って、価値を検証する方法を紹介します。
バグ修正
Codex によって、エンジニアは調査や手戻りを減らしながらバグを解決できていますか？
入力処理の誤りなど、あるサービスで繰り返し発生するバグの種類を選びます。そのコードに詳しいエンジニアとともに、問題、修正内容、リグレッションテストを確認します。
- 類似した修正を比較します。 複雑さが同程度のバグについて、調査、実装、レビューにかかった時間を記録します。実際に作業した時間と、レビューやリリースの待ち時間を分けてください。
- 「インサイト」を確認します。 「ソフトウェアエンジニアリング」を開き、調査に関連するタスクを探します。比較対象の期間について、クレジットとアクティブユーザーを確認します。
- 結果を確認します。 テストでバグを再現でき、修正後にはテストが通ることを確認します。エンジニアが何を修正したかを尋ね、再オープンされた問題やリグレッションを記録します。
- 検証済みの修正にかかる総工数が減っている場合は、そのワークフローを共有します。 手戻りが依然として多い場合は、再現手順やリポジトリのコンテキストを改善し、もう一度比較します。
テストの追加
Codex によって、チームは手作業を減らしながら重要な障害ケースをテストでカバーできていますか？
カバレッジの不足がわかっているモジュールを選びます。結果を比較する前に、テストが必要な動作と障害ケースについて合意します。
- 不足しているテストを明確にします。 テストで網羅できていない動作を列挙し、同程度のテストを追加するのに必要な工数を記録します。テストレポートを使って、開始時点のカバレッジを記録します。
- インサイトを確認します。 「ソフトウェアエンジニアリング」で関連するタスクを探します。同じ期間のクレジットと、表示されているモデル別・推論別の内訳を確認します。
- テストを精査します。 アサーションが意図した障害を検出できるか、エンジニアに確認してもらいます。不安定なテスト結果、実行時間の増加、テストの書き直しや保守にかかった時間を記録します。
- 有用なテストを取り込むまでの工数が減るなら、その方法を再利用します。 障害を検出せずにテストが通ってしまう場合は、期待する動作を明確にしてから再度試します。
コードのリファクタリング
Codex は、期待する動作を維持しながらリファクタリングを完了するうえで、チームの役に立っていますか？
パッケージ全体で非推奨の API を置き換えるなど、範囲を限定した変更を一つ選びます。対象とする呼び出し箇所と、チームで結果を検証する方法について合意します。
- 範囲を定めます。 更新する呼び出し箇所と、同程度の変更を手作業で行う場合の工数を記録します。特に、以前から先送りされていた作業では、見積もりであることを明記します。
- インサイトを確認します。 「ソフトウェアエンジニアリング」の関連タスクと、そのクレジットを同じ期間で確認します。消費量が目立つ場合は、表示されているモデル別・推論別の内訳を確認します。
- 変更を検証します。 差分をレビューし、関連するチェックを実行して、呼び出し箇所の更新漏れや動作の変化がないかを確認します。レビュー、修正、後から必要になった修正も工数に含めます。
- リファクタリングが合意したチェックを満たしていれば、別のパッケージにも対象を広げます。 手直しが多く残る場合は、まず変更範囲を絞るか、動作する例を提供します。
顧客リサーチ
ChatGPT Work は、営業担当者がより少ない工数で正確な顧客概要資料を作成するのに役立っていますか？
概要資料を定期的に作成する営業チームを選びます。顧客との取引履歴、現在の優先事項、顧客への質問など、各資料に含める内容について合意します。
- 同程度の概要資料を比較します。 試行前と試行中の作成時間およびレビュー時間を記録します。同じ品質基準を使い、同程度のリサーチが必要な顧客を対象にします。
- インサイトを確認します。 「営業」で顧客リサーチや計画に関するタスクを探します。利用できるグループフィルターを使って、対象チームに絞り込みます。同じ期間のクレジット、選択されたモデル、表示されているプラグインやスキルの利用状況を確認します。
- 営業担当者と一緒に概要資料をレビューします。 元の記録と照合して事実を確認し、リサーチが顧客との会話の準備に役立つかを評価します。修正も工数に含め、短縮できた時間が顧客との会話やフォローアップに使われているかを追跡します。
- 正確な概要資料をより少ない工数で作成できるなら、その方法を共有します。 重要な背景情報が不足している場合は、参照資料を改善するか、共有スキルを提供します。その後の有望な商談や売上の変化は、CRM の記録を使って評価します。インサイトだけでは、その関連性を裏付けることはできません。
在庫計画
ChatGPT Work は、チームがより少ない手作業で信頼できる在庫計画を作成するのに役立っていますか？
イベント用の在庫など、繰り返し行う計画サイクルを選びます。対象とする商品や拠点、チームが使用する販売記録と在庫記録について合意します。
- 現在のプロセスを記録します。 記録の収集、計画の作成、修正にかかる時間を測定します。比較可能なサイクルで発生した在庫不足や過剰在庫を記録します。
- インサイトを確認します。 チームの計画業務に合うカテゴリーとタスクを探します。同じ期間のクレジットとアクティブユーザー数を確認します。そのカテゴリーの利用状況をこのワークフローによるものと判断する前に、対応関係をチームに確認します。
- 計画と実績を照合します。 在庫管理の責任者に、数量、前提条件、不足しているデータを確認してもらいます。レビューと修正も工数に含めます。サイクル終了後に、計画した在庫を販売実績や残った在庫と比較します。
- 信頼できる計画をより少ない工数で作成できるなら、そのワークフローを再利用します。 在庫不足や過剰在庫が増える場合は、入力情報と前提条件を見直します。在庫記録と購買記録を使って、コスト削減の有無や程度を評価します。
評価を記録します。 ユースケース、責任者、報告対象期間を記載します。比較基準、結果、クレジット、評価の限界を含めます。チームと合意した変更と、その見直し日も記録します。完了した作業はチームの記録に基づいて集計し、推定値にはその旨を明記します。
ROI を評価するには、改善によって得られる価値を、AI、セットアップ、トレーニング、継続的なサポートのコストと比較します。作業のレビューや修正にかかった時間も含めます。時間の短縮が、そのまま金銭的な節約につながるとは限りません。生まれた余力をチームがどう活用しているかを確認します。
利用上限を引き上げる前に、現在の上限、消費量、追加の利用枠が必要な業務を確認します。消費したクレジットが、そのまま追加請求になるとは限りません。ChatGPT Work の利用量とコストをご覧ください。
利用状況の分析は、ChatGPT Work と Codex への投資効果を把握するための手がかりの一つです。選択した範囲での利用状況とクレジット消費量を示します。実際に作業するチームは、何が変わったのか、成果が改善したか、その改善にどのような価値があるかを説明できます。両方を活用して、どのワークフローを拡大するか、どこでチームへの支援を強化するかを判断します。