For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
Theme

共同作業と共有

Codex における ChatGPT Work の利用状況分析

ChatGPT Work と Codex の利用状況とクレジット消費量を把握し、チームのワークフローの価値を評価する方法を紹介します。

管理コンソールの「インサイト」では、チームがどのような業務に ChatGPT Work と Codex を使い、何にクレジットを消費しているかを確認できます。ワークスペースの概要でカテゴリを開くと、そのカテゴリのタスクと利用状況が表示されます。結果を比較する前に、各画面の集計対象を確認してください。

これらの画面から評価したいワークフローを選び、その業務の担当者と一緒に検討します。利用状況と支出をチームの業務記録と照らし合わせ、作業の手間が減ったか、品質基準を満たしているか、成果が向上したかを確認します。

分析画面

ChatGPT Work と Codex の利用状況は、管理コンソールで分析できます。「使用状況」にはアクティビティと消費量が表示されます。「インサイト」では、利用状況をカテゴリ別、タスク別に確認できます。エンジニアリング業務については、「コードレビュー」でレビューの実施状況と指摘事項を確認できます。

「ユースケース」タブには、カテゴリと各カテゴリの指標が表示されます。スクリーンショットにはサンプルデータを使用しています。

トークンについて調べる場合は、「使用状況」のトークン指標を使います。メッセージの割合、クレジットの割合、トークンの割合は、それぞれ異なる指標です。結果を比較したり共有したりする際も、指標名をそのまま使ってください。

インサイトの開き方

管理コンソールでワークスペースを選び、分析 > インサイト を開きます。そのワークスペースの分析データへのアクセス権が必要です。表示される画面とデータは、権限と有効な機能によって異なります。

結果を見る前に、ワークスペース、期間、利用できるフィルターを確認します。アクティビティを比較する際は、これらの条件をそろえてください。「インサイト」で参照できる履歴は、分類を開始した時点以降のものに限られます。

ユースケースとタスク

「概要」では、「ユースケース」と「タスク」を切り替えて、大まかなカテゴリ別に見ることも、より具体的な作業別に見ることもできます。「ユースケース」タブでカテゴリを展開すると、そのカテゴリのタスクが表示されます。

ユースケースの概要には、上位 10 カテゴリそれぞれがクレジット消費量に占める割合が表示されます。作業別に詳しく見るには「タスク」に切り替えます。

グラフでユースケースまたはタスクを選択すると、詳細が開きます。上位 10 件以外も含めてカテゴリやタスクを比較するには、ユースケース表を使います。

1 つのカテゴリに複数のワークフローが含まれることがあります。カテゴリを単一の業務プロセスとして扱う前に、含まれるタスクを確認してください。未分類のアクティビティがある場合は、結果を説明する際にその制約を明記します。

メッセージ、クレジット、アクティブユーザー

各カテゴリやタスクの利用状況を把握するには、表の「メッセージ」「クレジット」「アクティブユーザー」を併せて確認します。サンプリングに関する注記がある場合、表示される件数は抽出したアクティビティの集計値です。この件数をもとに、ワークスペース全体のアクティビティを推計しないでください。

ユースケースを展開すると、その中のタスクを比較できます。この例では「ソフトウェアエンジニアリング」を展開しています。

メッセージは、カテゴリまたはタスクに関連するメッセージの件数を示します。メッセージ数だけでは、チームがどれだけの作業を完了したかは分かりません。

クレジットの割合は、クレジット消費量のうち、そのカテゴリまたはタスクが占める割合を示します。「クレジット」「メッセージ」と併せて見ると、何に消費が集中しているかを把握できます。

アクティブユーザーは、そのカテゴリまたはタスクを利用した人数を示します。「メッセージ」と併せて見ると、カテゴリを利用した人数と、そこで発生したアクティビティの量を比較できます。

あるカテゴリがクレジット消費量の大きな割合を占める場合は、そのカテゴリのタスク、モデル、設定を確認します。作業の複雑さやモデルの選び方が消費量に影響している可能性があります。消費量に見合う価値があったかを判断する前に、チームが何を達成したかを確認してください。

アクティブユーザーが少ないカテゴリについては、利用者に、どのように使っているか、どこで困っているかを聞きます。他の人にも共有したいワークフローが見つかる場合も、追加のサポートが必要な場合もあります。

カテゴリの詳細

カテゴリの詳細を開くと、右側のパネルにそのカテゴリのタスクと利用状況の内訳が表示されます。

「ソフトウェアエンジニアリング」の詳細パネルには、タスクと、モデル別、推論別、速度別の内訳が表示されます。

カテゴリに含まれるタスクと、それぞれが消費したクレジットを確認します。モデル、推論、速度の内訳には、選択したカテゴリまたはタスクのクレジット消費量に占める各選択肢の割合が表示されます。消費量が変わった場合は、作業内容やこれらの設定に変更があったかをチームに確認してください。

データがある場合は、カテゴリまたはタスクごとに、プラグインとスキルの呼び出し回数を確認します。この回数には、選択した期間とフィルターに該当する ChatGPT Work と Codex の両方のアクティビティが含まれます。呼び出し回数は、メッセージ数や完了したタスクの件数とは異なります。

結果を共有する際は、推定値にはその旨を明記してください。プラグインとスキルに割り当てられたクレジットは重複する場合があるため、投資総額を求める際に両方の画面の値を合算しないでください。クレジットの見方と請求への影響については、ChatGPT Work の使用量と費用を参照してください。

コードレビュー

エンジニアリング業務を評価する場合は、コードレビューを開き、ワークスペースで利用できるレビュー指標を確認します。

  • レビュー済みの PR は、pull request のレビュー実施状況を示します。レビュー済みの pull request が必ずしもマージまたはデプロイされているとは限りません。
  • 検出された問題には、レビューでの指摘事項が表示されます。どの指摘が役に立ち、実際に対応につながったかをレビュアーに確認してください。
  • 優先度別の問題、リアクション、リアクションの傾向を見ると、指摘の内容と、それに対する反応をより詳しく把握できます。
「レビュー済みの PR」では、レビュー実施状況の推移を確認できます。この例ではサンプルデータを使用しています。

件数が 0 の場合、実際にアクティビティがなかった可能性も、記録に漏れがある可能性もあります。件数を解釈する前に、対象期間と、該当するレビューが集計に含まれているかを確認してください。

価値の評価

チームが ChatGPT Work または Codex を使っているワークフローを選びます。どの成果を改善したいか、どのように測定するかを業務責任者と決めます。「インサイト」と併せて、顧客概要資料、在庫計画、pull requests などの業務記録を確認します。評価には、実際に作業を担当している人にも参加してもらいます。

集計期間をそろえ、サンプリングに関する注記があれば確認してください。カテゴリには複数のワークフローが含まれることがあり、アクティビティの件数から完了した作業量は分かりません。以下の例では、利用データと実際の業務記録の両方から、ワークフローの価値を調べます。

バグ修正

Codex を使うことで、エンジニアは調査や手戻りにかかる工数を減らしてバグを修正できているでしょうか。

1 つのサービスで繰り返し発生するバグの種類を選びます。たとえば、入力処理の誤りが挙げられます。そのコードに詳しいエンジニアと一緒に、関連する課題、修正内容、回帰テストを確認します。

調査方法
  1. 類似した修正を比較します。 同程度の複雑さのバグについて、調査、実装、レビューにかかった時間を記録します。実作業の時間は、レビューやリリースの待ち時間と分けて集計します。
  2. 「インサイト」を確認します。 「ソフトウェアエンジニアリング」を開き、調査に関連するタスクを探します。比較対象期間のクレジット消費量とアクティブユーザー数を確認します。
  3. 修正結果を確認します。 テストでバグを再現でき、修正後はテストが通ることを確認します。エンジニアに修正内容を聞き、再オープンされた課題やリグレッションがあれば記録します。
  4. 修正を確認できたバグで総工数が減っていれば、ワークフローを共有します。 手戻りが依然として多い場合は、再現手順を改善するか、リポジトリについて提供するコンテキストを充実させて、再度比較します。

テストの追加

Codex を使うことで、チームは手作業を減らしながら、重要な異常系をテストできているでしょうか。

テストカバレッジに不足があると分かっているモジュールを選びます。結果を比較する前に、どの動作と異常系にテストが必要かをチームで決めます。

カテゴリの詳細の表示例です。画像を選択すると拡大できます。
調査方法
  1. テストの不足箇所を明確にします。 テストされていない動作を列挙し、同程度のテストを追加するのに必要な工数を記録します。テストレポートを使って、開始時点のカバレッジを記録します。
  2. 「インサイト」を確認します。 「ソフトウェアエンジニアリング」で関連するタスクを探します。同じ期間のクレジット消費量と、表示されるモデル別、推論別の内訳を確認します。
  3. テストの内容を検証します。 アサーションが想定した不具合を検出できるか、エンジニアに確認してもらいます。結果が不安定なテスト、実行時間の増加、テストの書き直しや保守にかかった時間を記録します。
  4. 有効なテストをより少ない工数で取り込めたら、同じ方法を活用します。 検出すべき不具合があってもテストが通る場合は、期待する動作を明確にして、もう一度試します。

コードのリファクタリング

Codex を使うことで、チームは期待される動作を維持したままリファクタリングを完了できているでしょうか。

あるパッケージ内で非推奨の API を置き換えるなど、範囲を明確にできる変更を 1 つ選びます。どの呼び出し箇所を対象とし、どのように結果を検証するかをチームで決めます。

調査方法
  1. 対象範囲を決めます。 更新する呼び出し箇所と、同程度の変更を手作業で行う場合の工数を記録します。工数が推定値であれば、その旨を明記します。特に、以前は作業を見送っていた場合は注意してください。
  2. 「インサイト」を確認します。 同じ期間について、「ソフトウェアエンジニアリング」の関連タスクとそのクレジット消費量を確認します。消費量が目立つ場合は、表示されるモデル別、推論別の内訳を確認します。
  3. 変更を検証します。 差分をレビューし、関連するチェックを実行して、更新漏れのある呼び出し箇所や動作の変化がないかを確認します。レビュー、修正、その後の追加修正にかかった時間も工数に含めます。
  4. 合意した検証項目をすべて満たせば、別のパッケージにも対象を広げます。 後処理が多く残る場合は、まず変更範囲を絞るか、動作する実例を用意します。

顧客調査

ChatGPT Work を使うことで、営業担当者は正確な顧客概要資料をより少ない工数で作成できているでしょうか。

顧客概要資料を定期的に作成している営業チームを選びます。顧客との取引履歴、現在の優先事項、顧客に尋ねたいことなど、各資料に含める内容をチームで決めます。

調査方法
  1. 条件の近い顧客概要資料を比較します。 試行前と試行中に、資料の準備とレビューにかかった時間を記録します。同程度の調査が必要な顧客を選び、同じ品質基準を使います。
  2. 「インサイト」を確認します。 「営業」で、顧客調査と計画に関連するタスクを探します。グループフィルターを使って対象チームに絞り込みます。同じ期間について、クレジット消費量、選択されたモデル、データがあればプラグインやスキルの利用状況も確認します。
  3. 営業担当者と一緒に資料をレビューします。 記載内容を元の記録と照合し、調査結果が顧客との対話の準備に役立つかを評価します。修正にかかった時間も工数に含め、短縮できた時間を顧客との対話やフォローアップに充てているかを追跡します。
  4. 正確な資料をより少ない工数で作成できたら、方法を共有します。 重要な背景情報が抜けている場合は、参照元の資料を改善するか、チームで共有できるスキルを用意します。その後の有望な商談や売上の変化は、CRM の記録を使って評価します。「インサイト」だけでは、今回の取り組みとの関連は判断できません。

在庫計画

ChatGPT Work を使うことで、チームは手作業を減らしながら、信頼できる在庫計画を作成できているでしょうか。

イベント用の在庫を計画する場合など、繰り返し行う計画業務を選びます。対象とする商品と拠点、チームが使用する販売記録と在庫記録を決めます。

調査方法
  1. 現在の手順を記録します。 記録の収集、計画の作成、修正にかかる時間を測定します。条件の近い過去の計画サイクルで発生した在庫不足や過剰在庫も記録します。
  2. 「インサイト」を確認します。 チームの計画業務に該当するカテゴリとタスクを探します。同じ期間のクレジット消費量とアクティブユーザー数を確認します。カテゴリの利用実績をこのワークフローのものとして扱う前に、実際の業務と対応しているかをチームに確認します。
  3. 計画と実績を照合します。 在庫管理の責任者に、数量、前提条件、データの欠落を確認してもらいます。レビューと修正にかかった時間も工数に含めます。計画期間が終わったら、計画した在庫数を実際の販売数および残りの在庫数と比較します。
  4. 信頼できる計画をより少ない工数で作成できたら、同じワークフローを活用します。 在庫不足や過剰在庫が増えた場合は、入力データと前提条件を見直します。費用がどれだけ削減できたかは、在庫記録と購買記録を使って評価します。

評価内容を記録します。 ユースケース、責任者、集計期間を明記し、比較の基準値、結果、クレジット消費量、評価上の制約を記載します。チームで合意した変更内容と、それを見直す日付も記録します。完了した作業の件数はチームの業務記録から集計し、推定値にはその旨を明記してください。

投資対効果(ROI)を評価するには、改善によって得られた価値を、AI の利用、導入、トレーニング、継続的なサポートにかかる費用と比較します。成果物のレビューと修正にかかった時間も含めてください。時間の短縮がそのまま支出の削減につながるとは限りません。生まれた余力をチームがどう使っているかを確認します。

利用上限を引き上げる前に、現在の上限と消費量を確認し、どの業務に追加の利用枠が必要かを検討します。クレジットを消費しても、自動的に追加料金が請求されるわけではありません。ChatGPT Work の使用量と費用を参照してください。

利用状況の分析は、ChatGPT Work と Codex への投資対効果を把握するための材料の 1 つです。「インサイト」では、選択した範囲の利用状況とクレジット消費量を確認できます。実際に業務を担当するチームからは、何が変わったか、成果が向上したか、その改善にどれほどの価値があるかを聞くことができます。分析データと現場の声を併せて、どのワークフローを広げるか、どこに追加のサポートが必要かを判断してください。