GPT-6 Astraの企業事例｜Canva・Box・Perplexityから考える試し方【2026年10月更新】

GPT-6 Astraの企業事例を見ると、資料を読ませるだけでなく、社内の情報を調べ、作業し、その結果を確認する使い方が報告されています。ただし、各社が用意したデータやツールも結果に関わります。

この記事では、OpenAIが公開したCanva・Box・Perplexityの活用・評価事例を取り上げます。各社の説明に続けて、自社で試す方法をMakeAIから提案します。情報確認日は2026年10月20日です。

3社は何を任せた？

企業	公開情報から確認できた用途
Canva	コード、社内データ、複数の情報源を使った調査と提案の評価
Box	企業の文書を扱う作業で、根拠のない断定を抑えられるかの評価
Perplexity	検索や分析を進めるプログラム、ソフトウェアの変更・テストへの利用

CanvaとBoxについては、OpenAIの法人向け紹介ページに掲載された各社担当者の説明を参照しています。試験の条件がすべて公開されているわけではないため、自社でも同じ結果が出るとは限りません。

Canva：複数の情報源を調べて提案する

Canvaは、Astraがコードベース、データウェアハウス、社内の知識やコミュニティの意見を調べ、提案したと報告しています。公開コメントは、Canvaの社内評価についての説明です。通常のCanva利用者が同じ社内環境を使えるという話ではありません。OpenAI掲載のCanvaの評価

自社で参考にするなら、「顧客アンケートと問い合わせ記録を読んで、改善案を出す」といった仕事が候補になります。その場合、改善案だけでなく、どの記録を根拠にしたかも出してもらうと、担当者が判断しやすくなります。

ここで必要なのは、読める資料を増やすことだけではありません。対象期間が違うアンケートを混ぜない、同じ問い合わせの重複を数えない、といった確認も必要です。

Box：文書に書かれていないことを断定させない

Boxは、企業の文書を扱う評価で、Astraが資料に裏付けられない結論を言い切らない点を挙げています。OpenAI掲載のBoxの評価

これは、社内の文書を読む仕事で確認したい点です。たとえば見積書に納期が書かれていないのに、「来月には納品できる」と埋められると、読み手は正式な条件だと思ってしまいます。

試すときは、すべての情報がそろった資料だけでなく、あえて一部が欠けた練習用資料も使います。答えを作ることと、足りない情報を質問することを、両方確認するためです。

練習用資料の状態	出力で確かめること
金額はあるが納期がない	納期を推測せず「記載なし」とするか
本文と表の合計が違う	どちらかを勝手に正しいとして処理しないか
旧版と新版がある	どの版を参照したか分かるか

この表は、自社で試すためにMakeAIが作成したものです。

Perplexity：ソフトウェアの変更とテストに使う

Perplexityの事例では、Astraをコミュニケーションの下書き、ソフトウェアの変更、運用中のシステムの監視に使う説明があります。テストでは、外部サービスが返すような応答を生成し、アプリがどう動くかを確かめる小さなプログラムを作っています。OpenAIが公開したPerplexityの事例

自社の開発で参考になるのは、正常に動く場面だけでなく、相手のサービスが遅い、空の値を返す、エラーになる、といった条件を確認する考え方です。

たとえば社内の問い合わせ分類システムなら、「本文が空」「分類できない内容」「保存先が応答しない」といった入力を使って、止まり方や担当者への知らせ方を確認できます。

自社で試すなら、まず1つの仕事を決める

事例を参考にする際は、会社全体の仕事をまとめて任せる前に、担当者が結果を確認できる範囲を選びます。

1. 作るものを決める。 たとえば、アンケート10件から作る改善メモ。
2. 材料をそろえる。 対象期間、記録、集計ルールを用意する。
3. 確認用の資料も入れる。 情報の欠落や数字の食い違いを含む例を用意する。
4. 結果を照合する。 根拠、数字、依頼した項目を確認する。
5. 直す時間を記録する。 AIが出力するまでの時間だけで比べない。

依頼する内容は、次のように書けます。

添付の練習用アンケート10件から、改善メモを作ってください。
対象は申込み手順についての意見です。

意見をまとめる際は、根拠となる記録番号を付けてください。
件数から言えることと、推測した原因を分けてください。
資料にない顧客の発言は作らないでください。
最後に、担当者へ確認したい点を3つ以内で挙げてください。

何を渡すか迷う場合は、業務用プロンプトの基本も参考にしてください。

事例を読むときに確認したいこと

「処理時間が短くなった」「費用が下がった」という数字があっても、比較相手、作業内容、使ったツール、確認にかかった時間が違えば、そのまま自社の見積もりには使えません。掲載された数字が、会社の本番運用の結果なのか、社内試験なのかも確認します。

今回の3社から、自社で試す題材は見つけられます。導入を決めるときには、自分たちの資料で必要な結果が出るかを確かめます。

事例から自社へ持ち帰るのは、会社名より作業の条件

大企業の事例をそのまま自社の計画へ当てはめると、必要な資料や運用体制が抜けることがあります。参考にしたいのは、どの入力を渡し、どの作業を任せ、何を確認して成果としたかです。モデルの性能だけでなく、検索できる社内情報、使えるツール、評価する担当者も結果へ関係します。

事例を読むときは、「確認できた説明」「公開されていない条件」「自社で試す案」の三つに分けてメモします。たとえば、企業が社内資料を横断して提案を得たと説明していても、権限設定や評価用データの詳細が分からないなら、それは未公開の条件です。自社でアンケート十件を使って試す案は、その事例の再現実験ではありません。

確認する項目	事例を読むときの問い	自社で決める内容
入力	どの種類の資料を使ったか	試行で使う資料と対象期間
環境	API、アプリ、社内ツールのどれか	自社で利用できる接続先
作業	調査、実行、確認のどこを任せたか	今回任せる範囲
評価	何と比べ、誰が確認したか	合格条件と確認担当者
不足	公開情報だけでは何が分からないか	試行で追加確認すること

Canvaの事例を参考に、問い合わせの改善案を作る

ここからはMakeAIが作成した仮の試行案です。実在企業の導入実績や、Astraで実行した結果ではありません。問い合わせ記録とアンケートを使い、申込み手順の改善候補を考えます。入力には、記録番号、受付日、対象の手続き、発言内容をそろえます。顧客の発言と担当者の解釈は別の列にします。

最初に同じ問い合わせの重複を確認します。電話とメールの両方で記録された一件を二人の意見として数えると、件数が増えて見えます。また、既存利用者のアンケートと新規申込者の問い合わせでは対象者が違います。混ぜて集計するなら、その違いを残します。単に多い順へ並べる前に、何件を何の母集団として数えているかを決めます。

問い合わせ記録とアンケートから、申込み手順の改善候補を作ってください。
まず資料ごとの対象期間、対象者、件数を確認してください。
重複の可能性がある記録は番号を示し、勝手に除外しないでください。
候補ごとに、根拠となる記録番号、困っている場面、考えられる対応を示してください。
頻度が高いことと、事業への影響が大きいことを区別してください。
推測した原因は仮説と書き、実際の顧客発言のように引用しないでください。
最後に、担当者が確認すべき三つの質問を挙げてください。

出力後は、上位の改善案だけでなく、採用しなかった意見も確認します。少数でも申込みを完了できない問題が含まれる場合があるためです。「件数が多いので最優先」と自動で決めず、影響、対応の手間、確認できた根拠を並べ、人が優先順位を判断します。

Boxの事例を参考に、未記載を確認する課題を作る

企業の資料を扱う仕事では、記載のないことを断定しない動作が重要です。試行用には、正常な資料だけでなく、料金はあるが納期がない、契約期間はあるが更新条件がない、といった架空の資料を用意します。読み手が答えを求めたときに、資料にない条件をどのように扱うかを確認します。

たとえば「この条件なら来月から開始できるか」という質問に対し、資料に開始可能日がなければ、そのことを示す必要があります。料金の掲載があるから開始できる、問い合わせ先があるから空きがある、といった推測は確定情報にしません。出典が付いていても、その出典に開始日が書かれていなければ回答の根拠にはなりません。

確認表には、答えがある項目と、ない項目を同じ数だけ用意する必要はありません。実務で間違えると困る条件を選びます。出力を評価するときは、正しく答えられた件数だけでなく、未確認を未確認として扱えたかも記録します。分からないと回答することが多すぎる場合は、資料のどの箇所を読めなかったのかを確認します。

不足を見つけた後の仕事まで決める

未記載と分かっても、確認先がないと業務は進みません。試行では、足りない項目、確認先、返答を得た後に更新する箇所を一覧にします。AIが問い合わせ先へ連絡するところまで自動で任せる必要はありません。まず確認事項を整理し、人が内容を確かめてから次の行動へ進めます。

Perplexityの事例を参考に、失敗する条件を試す

ソフトウェアの試行では、正常な入力だけを通しても、業務で止まる場面が分かりません。問い合わせ分類の仮の仕組みなら、本文が空、文字が非常に長い、分類先が見つからない、保存先が応答しない、といった条件を用意します。期待する動作は、すべてを無理に分類することではなく、分からないものを担当者へ回すことも含みます。

試験用の応答を作る場合は、それが実際の外部サービスの返答と同じではないことを記録します。テスト用の入力で動いたことは確認できますが、本番接続、通信条件、権限、実データの形式まで確認したことにはなりません。最終的には自社の環境で必要な経路を確認する必要があります。

問い合わせ分類の試験計画を作ってください。
正常な入力に加え、空欄、分類不能、保存先エラーを扱ってください。
各条件について、入力、期待する動作、確認方法を記載してください。
テスト用に作る応答と、本物の外部サービスで確認する箇所を分けてください。
実行していない項目は未実行と書き、成功したことにしないでください。

失敗時の動作を決めるときは、同じ問い合わせが二重に保存されないか、途中の記録が消えないか、担当者が再開できるかも考えます。分類結果だけを採点するより、入力から担当者が結果を受け取るまでを確認したほうが、実運用の課題を見つけやすくなります。

小規模な試行の結果を、導入判断へつなげる

試行を終えたら、入力の種類、実行した件数、合格した条件、修正が必要だった条件をまとめます。「九割正解」という数字だけでは、残りの一割がどの業務へ影響するか分かりません。数字の誤り、根拠の不足、形式の崩れを分け、実際に使う前に人が何を確認するかを決めます。

企業事例の改善率を自社の予算資料へそのまま転記することは避けます。自社で測った作業時間、修正時間、利用料を使い、試していない仕事は対象外と記載します。今回の三社の情報は2026年10月20日に公開一次資料を再確認しました。各社の説明とMakeAIの試行案を区別し、再現できる部分から評価を進めてください。

事例に載っていない運用コストを質問へ残す

公開事例では、導入前の資料整理や、接続の設定、結果を確認する担当者の時間まで詳しく分からないことがあります。自社の導入計画では、その準備が必要かを別に調べます。モデルへの支払いだけを見て、資料の管理や人の確認が不要になる前提を置かないようにします。

試行前の確認では、誰が正本を用意するか、誤った結果を誰が直すか、元資料が更新されたら誰が反映するかを決めます。特別な役職を増やす必要はありませんが、既存の担当者のどの作業に含めるかは明確にします。試行が終わってから担当を探すと、良い出力があっても継続できない場合があります。

事例を社内で紹介するときは、企業が報告した事実、公開されていない条件、自社の試行案を同じスライドでも区別します。仮の見積もりや期待する効果にはその旨を記載し、他社の実績を自社の確定した成果として説明しないでください。

小さな試行でも、入力と確認結果が残っていれば、次にどの業務へ広げるか判断できます。企業名の知名度ではなく、自社と共通する作業条件を根拠に選んでください。