【ITニュース解説】From Scraps to Structure: Reliably Extracting Actions with My GPT for Asana

会議でメモを取る行為は、多くの人が日常的に行っている作業だが、そのメモから具体的な「やるべきこと（アクションアイテム）」と「担当者」を抽出し、タスク管理ツールに登録する作業は非常に手間がかかる。この非効率な作業を自動化したいという願望は古くから存在し、その解決策としてAI技術、特にカスタムGPT（Generative Pre-trained Transformer）の活用が期待された。

筆者は、会議の自由形式なメモからアクションアイテムを抽出し、それらをタスク管理ツールであるAsanaに自動的に登録することを夢見て、カスタムGPTの導入を試みた。当初の計画はシンプルで、GPTに会議メモを入力し、抽出されたアクションアイテムをJSON形式で受け取り、それをAsanaに送信するというものだった。GPT-4 Turboという高性能なモデルを使用し、最初の指示は「アクションアイテムと担当者またはチームを特定し、JSON配列形式で出力してください」という比較的高レベルなものだった。しかし、この最初の試みは期待通りの結果をもたらさなかった。

GPTの出力は驚くほど一貫性がなく、時にはJSONのキー名が異なったり、求められた形式を無視して会議の要約を出力したり、メモには記載されていない担当者やチームをでっち上げたりすることもあった。まるで「もぐらたたき」のように、次から次へと異なる種類の問題が発生した。筆者は一週間で10時間以上を費やし、プロンプトの調整を試みた。具体的には、「常にJSON形式で出力し、キーはaction_description、responsible_team、responsible_personとすること。個人名がない場合はnullを使用する」といった、より具体的な指示を与えた。完璧なJSON出力例をいくつか提示したり、GPTを「脅す」ような感情的な指示を試したりもしたが、どれも根本的な解決には至らなかった。最大の問題は、一般的に正しい出力が得られても、その「信頼性」に欠ける点だった。Asanaに不正確なデータを送り続ければ、それは別の種類の混乱を生むだけであった。

この状況を打開する転換点となったのは、カスタムGPTを単独の完全な解決策と捉えることをやめ、強力ではあるものの間違いを犯す可能性のある「最初の処理段階」と見なすようになったことだ。実際の解決策は、二つの主要な要素を連携させることによって実現された。

一つは、非常に厳格な「システムメッセージ」の適用である。単なるユーザープロンプトではなく、カスタムGPTのシステムメッセージ（APIを直接利用する場合はシステムロール）に詳細な指示を組み込んだ。システムメッセージは、モデルの基本的な動作原理を設定するために非常に重要である。筆者のシステムメッセージには、「あなたは自由形式の会議メモから構造化されたアクションアイテムを抽出する専門アシスタントです。唯一の出力は、アクションアイテムを表すオブジェクトのJSON配列でなければなりません。各オブジェクトは、task_description（タスクの簡潔な説明）、responsible_team（担当チーム名）、responsible_person（担当者の氏名、特定できない場合はnull）というキーを必ず持たなければなりません。このJSON構造を厳守し、JSONの前後に会話文を含めないでください。アクションアイテムが見つからない場合は空の配列 [] を返してください」といった内容が盛り込まれた。この厳密な指示により、GPTはかなり期待に近い、構造化されたJSONを出力するようになった。

もう一つは、出力の検証とAsanaへの連携を担う、小規模で特化したPythonスクリプトの導入である。これが真の決定打となった。このスクリプトはいくつかの重要な役割を果たす。まず、GPTの出力を受け取り、jsonschemaというライブラリを使って、それが期待するJSONスキーマに実際に準拠しているかを厳しく検証する。もし不適合な点があれば、スクリプトは即座にエラーを検知し、問題があることを知らせる。これにより、不正確なデータがAsanaに登録されることを未然に防ぐことができる。

次に、このスクリプトは「担当者マッピング」を行う。Asanaのようなタスク管理ツールは、単なるテキストのチーム名や個人名ではなく、内部で使われる特定のIDを必要とする場合が多い。スクリプトには、一般的なチーム名（例：「マーケティング」）をAsanaのプロジェクトIDやカスタムフィールド値に、そして個人名（例：「山田 太郎」）をAsanaのユーザーIDにマッピングするための辞書が組み込まれている。GPTの出力がこのルックアップテーブルに一致しない場合、スクリプトはエラーを通知するか、あるいは類似する名前を推測してマッチングを試みる。

最後に、検証とマッピングが完了したデータを使用して、スクリプトはasanaというPythonクライアントライブラリを介してAsana APIと連携する。これにより、新しいタスクの作成、担当者の割り当て、そして適切なプロジェクトへのタスク追加が自動的に行われる。特定の担当者が明記されていないタスクの場合、スクリプトが事前に設定されたチームのリーダーなどに割り当てるなど、状況に応じた柔軟な処理も可能になる。

この二段階のアプローチ、すなわち、厳格なシステムメッセージでGPTに高品質な構造化JSONを出力させ、その出力をPythonスクリプトでさらに検証・整形・連携するという方法が、すべてを変えた。現在では、約95%の精度でアクションアイテムがAsanaにスムーズに流れ込むようになり、以前手作業で行っていたデータ入力にかかる週に約2時間の時間を節約できている。残りの5%のエラーはスクリプトによってフラグが立てられるため、手動で簡単に修正できる範囲である。

この経験が示唆するのは、単にプロンプトを工夫する「プロンプトエンジニアリング」だけでは不十分だということである。AIは自然言語を解析する上で非常に強力なツールだが、それを信頼性の高い「本番環境対応」のシステムとして機能させるためには、決定的なロジックを持つコードによる検証と統合の層が必要不可欠である。AIの能力を最大限に引き出し、現実世界の問題を解決するには、AIと従来のプログラミングを組み合わせたハイブリッドなシステム構築が鍵となる。