AI自動カテゴリ分類（エンジニアリング詳細解説）

Blueエンジニアリングチームが、AI搭載の自動カテゴリ分類・タグ付け機能の開発舞台裏を解説します。

最近、AI自動カテゴリ分類をすべてのBlueユーザーに向けてリリースしました。これは、追加費用なしでBlueのコアサブスクリプションに含まれるAI機能です。この記事では、この機能を実現するためのエンジニアリングについて詳しく解説します。

Blueにおける機能開発のアプローチは、ユーザーニーズと市場トレンドの深い理解に根ざしており、同時にプラットフォームを定義するシンプルさと使いやすさを維持することへのコミットメントと結びついています。これが私たちのロードマップを推進し、長年にわたって毎月機能をリリースし続けることを可能にしている理由です。

BlueへのAI搭載自動タグ付けの導入は、この哲学を実践した完璧な例です。この機能をどのように構築したかの技術的な詳細に入る前に、私たちが解決しようとしていた問題と、その開発に込められた慎重な検討を理解することが重要です。

プロジェクト管理の状況は急速に進化しており、AI機能がユーザーの期待の中心になりつつあります。私たちの顧客、特に何百万ものレコードを含む大規模なプロジェクトを管理している顧客は、データをより賢く、より効率的に整理・分類する方法について強い要望を寄せていました。

しかし、Blueでは、単にトレンドであるから、あるいはリクエストされたからという理由で機能を追加することはありません。私たちの哲学は、すべての新機能がその価値を証明しなければならないというもので、機能が強い需要と明確な有用性を示すまで、デフォルトの答えは断固たる*「ノー」*です。

問題の深さとAI自動タグ付けの可能性を真に理解するため、私たちは広範な顧客インタビューを実施し、複数のドメインにわたって複雑でデータが豊富なプロジェクトを管理している長年のユーザーに焦点を当てました。

これらの会話から共通の糸が明らかになりました：タグ付けは整理と検索性において貴重でしたが、そのプロセスの手動性がボトルネックになりつつあり、特に大量のレコードを扱うチームにとってはそうでした。

しかし、私たちは手動タグ付けの当面の痛みを解決するだけでなく、それ以上のものを見ていました。

私たちは、AI搭載のタグ付けがより知的で自動化されたワークフローの基盤となる未来を思い描いていました。

この機能の真の力は、私たちのプロジェクト管理自動化システムとの潜在的な統合にあることに気づきました。情報を知的に分類するだけでなく、それらのカテゴリを使用してタスクをルーティングし、アクションをトリガーし、リアルタイムでワークフローを適応させるプロジェクト管理ツールを想像してみてください。

このビジョンは、Blueをシンプルかつパワフルに保つという私たちの目標と完全に一致していました。

さらに、この機能をプラットフォームの枠を超えて拡張する可能性も認識していました。堅牢なAIタグ付けシステムを開発することで、すぐに使える「カテゴリ分類API」の基盤を築いており、ユーザーがより広範な技術エコシステムでBlueと相互作用し、活用する新しい道を開く可能性があります。

したがって、この機能は単に機能リストにAIのチェックボックスを追加することではありませんでした。

それは、シンプルさとユーザー中心主義という私たちのコア哲学に忠実でありながら、より知的で適応的なプロジェクト管理プラットフォームへの重要な一歩を踏み出すことでした。

以下のセクションでは、このビジョンを実現する際に直面した技術的な課題、それをサポートするために設計したアーキテクチャ、実装したソリューションについて詳しく説明します。また、この機能が開く将来の可能性も探り、慎重に検討された追加がプロジェクト管理における変革的な変化への道を開くことができることを示します。

問題

上記で説明したように、プロジェクトレコードの手動タグ付けは時間がかかり、一貫性に欠ける可能性があります。

私たちは、レコードの内容に基づいて自動的にタグを提案するAIを活用することで、これを解決しようとしました。

主な課題は以下の通りでした：

適切なAIモデルの選択
大量のレコードの効率的な処理
データプライバシーとセキュリティの確保
既存のアーキテクチャへのシームレスな機能統合

AIモデルの選択

OpenAI、HuggingFaceのオープンソースモデル、Replicateを含む、いくつかのAIプラットフォームを評価しました。

私たちの基準には以下が含まれていました：

コスト効率
コンテキスト理解の精度
特定の出力フォーマットに従う能力
データプライバシーの保証

徹底的なテストの後、OpenAIのGPT-3.5 Turboを選択しました。GPT-4は精度の面でわずかな改善をもたらすかもしれませんが、私たちのテストでは、GPT-3.5のパフォーマンスが自動タグ付けのニーズに対して十分以上であることが示されました。コスト効率と強力なカテゴリ分類能力のバランスが、この機能にとってGPT-3.5を理想的な選択にしました。

GPT-4のより高いコストは、エンドユーザーに追加コストなしでメイン製品内にAIをバンドルするという私たちの目標と矛盾し、この機能を有料アドオンとして提供することを余儀なくされたでしょう。

実装時点でのGPT-3.5 Turboの価格は以下の通りです：

入力トークン1Kあたり$0.0005（または入力トークン1Mあたり$0.50）
出力トークン1Kあたり$0.0015（または出力トークン1Mあたり$1.50）

Blueの平均的なレコードについていくつかの仮定をしてみましょう：

タイトル: 約10トークン
説明: 約50トークン
2つのコメント: それぞれ約30トークン
5つのカスタムフィールド: それぞれ約10トークン
リスト名、期日、その他のメタデータ: 約20トークン
システムプロンプトと利用可能なタグ: 約50トークン

レコードあたりの合計入力トークン: 10 + 50 + (30 * 2) + (10 * 5) + 20 + 50 ≈ 240トークン

出力については、レコードあたり平均3つのタグが提案されると仮定し、JSONフォーマットを含めて合計約20の出力トークンになる可能性があります。

100万レコードの場合：

入力コスト: (240 * 1,000,000 / 1,000,000) * $0.50 = $120
出力コスト: (20 * 1,000,000 / 1,000,000) * $1.50 = $30

100万レコードの自動タグ付けの総コスト: $120 + $30 = $150

GPT3.5 Turboのパフォーマンス

カテゴリ分類は、GPT-3.5 Turboのような大規模言語モデル（LLM）が得意とするタスクであり、私たちの自動タグ付け機能に特に適しています。LLMは膨大な量のテキストデータで訓練されており、コンテキスト、意味論、概念間の関係を理解することができます。この広範な知識ベースにより、幅広いドメインにわたって高い精度でカテゴリ分類タスクを実行できます。

プロジェクト管理のタグ付けという私たちの特定のユースケースに対して、GPT-3.5 Turboはいくつかの重要な強みを示しています：

文脈理解: 個々の単語だけでなく、説明全体、コメント、その他のフィールドによって伝えられる意味を考慮して、プロジェクトレコードの全体的なコンテキストを把握できます。
柔軟性: 広範な再プログラミングを必要とせずに、さまざまなプロジェクトタイプや業界に適応できます。
曖昧さの処理: 複数の要因を考慮して、ニュアンスのある決定を下すことができます。
例からの学習: 追加のトレーニングなしで、新しいカテゴリ分類スキームを迅速に理解し、適用できます。
マルチラベル分類: 単一のレコードに対して複数の関連するタグを提案できます。これは私たちの要件にとって重要でした。

GPT-3.5 Turboは、既存のシステムとのシームレスな統合に不可欠であった、必要なJSON出力フォーマットへの準拠における信頼性でも際立っていました。オープンソースモデルは有望でしたが、しばしば余分なコメントを追加したり、期待されるフォーマットから逸脱したりして、追加の後処理を必要としたでしょう。この出力フォーマットの一貫性は、実装を大幅に簡素化し、潜在的な障害点を減らしたため、私たちの決定における重要な要因でした。

一貫したJSON出力を持つGPT-3.5 Turboを選択することで、より簡単で信頼性が高く、保守可能なソリューションを実装することができました。

フォーマットの信頼性が低いモデルを選択していた場合、次のような一連の複雑さに直面したでしょう：さまざまな出力フォーマットを処理するための堅牢な解析ロジックの必要性、一貫性のない出力に対する広範なエラー処理、追加処理による潜在的なパフォーマンスへの影響、すべての出力バリエーションをカバーするためのテストの複雑さの増加、そしてより大きな長期的な保守負担。

解析エラーは不正確なタグ付けにつながり、ユーザーエクスペリエンスに悪影響を与える可能性があります。これらの落とし穴を回避することで、予測不可能なAI出力と格闘するのではなく、パフォーマンスの最適化やユーザーインターフェースの設計などの重要な側面にエンジニアリングの努力を集中させることができました。

システムアーキテクチャ

私たちのAI自動タグ付け機能は、シームレスなユーザーエクスペリエンスを提供しながら、大量のリクエストを効率的に処理できるよう設計された、堅牢でスケーラブルなアーキテクチャ上に構築されています。すべてのシステムと同様に、この機能を現在経験しているトラフィックよりも1桁多いトラフィックをサポートするように設計しました。このアプローチは、現在のニーズに対して過度に設計されているように見えるかもしれませんが、使用量の突然の急増をシームレスに処理でき、大規模なアーキテクチャの見直しなしに成長のための十分な余地を与えるベストプラクティスです。そうでなければ、18か月ごとにすべてのシステムを再設計しなければならないでしょう - これは過去に苦労して学んだことです！

システムのコンポーネントとフローを詳しく見てみましょう：

ユーザーインタラクション: プロセスは、ユーザーがBlueインターフェースで「自動タグ」ボタンを押すことから始まります。このアクションが自動タグ付けワークフローをトリガーします。
Blue APIコール: ユーザーのアクションは、Blueバックエンドへの APIコールに変換されます。このAPIエンドポイントは、自動タグ付けリクエストを処理するように設計されています。
キュー管理: 高負荷時にパフォーマンスの問題につながる可能性のあるリクエストをすぐに処理する代わりに、タグ付けリクエストをキューに追加します。このキューイングメカニズムにはRedisを使用しており、負荷を効果的に管理し、システムのスケーラビリティを確保できます。
バックグラウンドサービス: 新しいリクエストのキューを継続的に監視するバックグラウンドサービスを実装しました。このサービスは、キューに入れられたリクエストの処理を担当します。
OpenAI API統合: バックグラウンドサービスは必要なデータを準備し、OpenAIのGPT-3.5モデルへのAPIコールを行います。ここで実際のAI搭載のタグ付けが行われます。関連するプロジェクトデータを送信し、提案されたタグを受け取ります。
結果処理: バックグラウンドサービスは、OpenAIから受け取った結果を処理します。これには、AIの応答の解析とプロジェクトへの適用のためのデータの準備が含まれます。
タグの適用: 処理された結果は、プロジェクト内の関連アイテムに新しいタグを適用するために使用されます。このステップは、AI提案のタグでデータベースを更新します。
ユーザーインターフェースへの反映: 最後に、新しいタグがユーザーのプロジェクトビューに表示され、ユーザーの観点から自動タグ付けプロセスが完了します。

このアーキテクチャは、システムパフォーマンスとユーザーエクスペリエンスの両方を向上させるいくつかの重要な利点を提供します。キューとバックグラウンド処理を利用することで、印象的なスケーラビリティを達成し、システムを圧倒したり、OpenAI APIのレート制限に達したりすることなく、多数のリクエストを同時に処理できるようになりました。このアーキテクチャの実装には、最適なパフォーマンスと信頼性を確保するために、さまざまな要因を慎重に検討する必要がありました。キュー管理には、分散キューの処理における速度と信頼性を活用して、Redisを選択しました。

このアプローチは、機能の全体的な応答性にも貢献しています。実際のタグ付けに時間がかかる場合でも、ユーザーはリクエストが処理されているという即座のフィードバックを受け取り、リアルタイムの相互作用の感覚を作り出します。アーキテクチャのフォールトトレランスは、もう1つの重要な利点です。一時的なOpenAI APIの中断など、プロセスの一部で問題が発生した場合、システム全体に影響を与えることなく、優雅に再試行したり、障害を処理したりできます。

この堅牢性は、タグのリアルタイム表示と組み合わされて、ユーザーエクスペリエンスを向上させ、AIの「魔法」が機能しているような印象を与えます。

データとプロンプト

自動タグ付けプロセスの重要なステップは、GPT-3.5モデルに送信するデータの準備です。このステップでは、正確なタグ付けのための十分なコンテキストを提供することと、効率性を維持し、ユーザーのプライバシーを保護することのバランスを取るために慎重な検討が必要でした。データ準備プロセスの詳細を見てみましょう。

各レコードについて、以下の情報をコンパイルします：

リスト名: プロジェクトのより広いカテゴリまたはフェーズに関するコンテキストを提供します。
レコードタイトル: レコードの目的や内容に関する重要な情報が含まれていることがよくあります。
カスタムフィールド: テキストおよび数値ベースのカスタムフィールドを含めます。これらには、プロジェクト固有の重要な情報が含まれていることがよくあります。
説明: 通常、レコードに関する最も詳細な情報が含まれています。
コメント: タグ付けに関連する可能性のある追加のコンテキストや更新を提供できます。
期日: タグの選択に影響を与える可能性のある時間的情報。

興味深いことに、既存のタグデータをGPT-3.5に送信しません。これは、モデルにバイアスをかけないためです。

自動タグ付け機能の核心は、GPT-3.5モデルとの相互作用の方法とその応答の処理方法にあります。パイプラインのこのセクションは、正確で一貫性があり、効率的なタグ付けを確保するために慎重な設計が必要でした。

AIにタスクを指示するために、慎重に作成されたシステムプロンプトを使用します。プロンプトと各コンポーネントの根拠の内訳は次のとおりです：

You will be provided with record data, and your task is to choose the tags that are relevant to the record.
You can respond with an empty array if you are unsure.
Available tags: ${tags}.
Today: ${currentDate}.
Please respond in JSON using the following format:
{ "tags": ["tag-1", "tag-2"] }

タスク定義: 焦点を絞った応答を確保するために、AIのタスクを明確に述べます。
不確実性の処理: AIが確信が持てない場合に強制的なタグ付けを防ぐため、空の応答を明示的に許可します。
利用可能なタグ: AIの選択を既存のプロジェクトタグに制限するために、有効なタグのリスト（${tags}）を提供します。
現在の日付: ${currentDate}を含めることで、AIが時間的コンテキストを理解するのに役立ちます。これは特定のタイプのプロジェクトにとって重要です。
応答フォーマット: 簡単な解析とエラーチェックのためにJSONフォーマットを指定します。

このプロンプトは、広範なテストと反復の結果です。タスク、利用可能なオプション、および望ましい出力フォーマットについて明示的であることが、AIの応答の精度と一貫性を大幅に改善することがわかりました - シンプルさが鍵です！

利用可能なタグのリストはサーバー側で生成され、プロンプトに含める前に検証されます。特大のプロンプトを防ぐために、タグ名に厳格な文字制限を実装しています。

上記のように、GPT-3.5 Turboで正しいフォーマットの純粋なJSON応答を100%の確率で取得することに問題はありませんでした。

要約すると、

システムプロンプトと準備されたレコードデータを組み合わせます。
この組み合わされたプロンプトは、OpenAIのAPIを介してGPT-3.5モデルに送信されます。
AIの応答における創造性と一貫性のバランスを取るために、0.3の温度設定を使用します。
APIコールには、応答サイズを制限し、コストを制御するためのmax_tokensパラメータが含まれています。

AIの応答を受け取ったら、提案されたタグを処理して適用するためにいくつかのステップを経ます：

JSON解析: 応答をJSONとして解析しようとします。解析が失敗した場合、エラーをログに記録し、そのレコードのタグ付けをスキップします。
スキーマ検証: 解析されたJSONを期待されるスキーマ（「tags」配列を持つオブジェクト）に対して検証します。これにより、AIの応答における構造的な逸脱をキャッチします。
タグ検証: 提案されたタグを有効なプロジェクトタグのリストと照合します。このステップは、AIが誤解した場合やプロンプトの作成と応答処理の間にプロジェクトタグが変更された場合に発生する可能性のある、プロジェクトに存在しないタグをフィルタリングします。
重複排除: 冗長なタグ付けを避けるために、AIの提案から重複するタグを削除します。
適用: 検証され、重複が排除されたタグは、データベース内のレコードに適用されます。
ロギングと分析: 最終的に適用されたタグをログに記録します。このデータは、システムのパフォーマンスを監視し、時間の経過とともに改善するために貴重です。

課題

BlueでAI搭載の自動タグ付けを実装することは、いくつかのユニークな課題を提示し、それぞれが堅牢で効率的でユーザーフレンドリーな機能を確保するための革新的なソリューションを必要としました。

一括操作の取り消し

AIタグ付け機能は、個々のレコードに対しても一括でも実行できます。一括操作の問題は、ユーザーが結果を気に入らない場合、何千ものレコードを手動で確認し、AIの作業を元に戻さなければならないことです。明らかに、それは受け入れられません。

これを解決するために、革新的なタグ付けセッションシステムを実装しました。各一括タグ付け操作には一意のセッションIDが割り当てられ、そのセッション中に適用されたすべてのタグに関連付けられます。これにより、特定のセッションIDに関連付けられたすべてのタグを削除するだけで、取り消し操作を効率的に管理できます。また、関連する監査証跡も削除し、取り消された操作がシステムに痕跡を残さないようにします。このアプローチにより、ユーザーは必要に応じて簡単に変更を元に戻せることを知って、AIタグ付けを実験する自信を得ることができます。

データプライバシー

データプライバシーは、私たちが直面したもう1つの重要な課題でした。

ユーザーは私たちにプロジェクトデータを託しており、この情報がOpenAIによって保持されたり、モデルのトレーニングに使用されたりしないことを確実にすることが最も重要でした。私たちは複数の面からこれに取り組みました。

まず、モデルのトレーニングのための私たちのデータの使用を明示的に禁止するOpenAIとの合意を結びました。さらに、OpenAIは処理後にデータを削除し、プライバシー保護の追加層を提供します。

私たちの側では、AIに送信されるデータから担当者の詳細などの機密情報を除外する予防措置を講じました。これにより、特定の個人の名前が他のデータと一緒に第三者に送信されないことが保証されます。

この包括的なアプローチにより、最高水準のデータプライバシーとセキュリティを維持しながら、AI機能を活用できます。

レート制限とエラーキャッチ

私たちの主な懸念事項の1つは、スケーラビリティとレート制限でした。各レコードに対する直接的なAPIコールはOpenAIに対して非効率的であり、特に大規模なプロジェクトやピーク使用時には、すぐにレート制限に達する可能性があります。これに対処するために、リクエストをバッチ処理し、独自のキューイングシステムを実装できるバックグラウンドサービスアーキテクチャを開発しました。このアプローチは、APIコールの頻度を管理するのに役立ち、大量のレコードのより効率的な処理を可能にし、重い負荷の下でもスムーズなパフォーマンスを確保します。

AIの相互作用の性質上、時折のエラーや予期しない出力に備える必要もありました。AIが無効なJSONを生成したり、期待されるフォーマットと一致しない出力を生成したりするケースがありました。これに対処するために、システム全体に堅牢なエラー処理と解析ロジックを実装しました。AI応答が有効なJSONでない場合、または期待される「tags」キーが含まれていない場合、私たちのシステムは、潜在的に破損したデータを処理しようとするのではなく、タグが提案されなかったかのように扱うように設計されています。これにより、AIの予測不可能性に直面しても、システムが安定して信頼性を保つことが保証されます。

今後の開発

私たちは、機能、そしてBlue製品全体が決して「完成」することはないと信じています - 常に改善の余地があります。

初期構築で検討したが、スコーピングフェーズを通過しなかったいくつかの機能がありましたが、将来的にそれらのいくつかのバージョンを実装する可能性が高いため、注目に値します。

最初はタグの説明を追加することです。これにより、エンドユーザーはタグに名前と色だけでなく、オプションの説明も付けることができます。これもAIに渡され、さらなるコンテキストを提供し、精度を向上させる可能性があります。

追加のコンテキストは価値があるかもしれませんが、それがもたらす可能性のある複雑さに注意を払っています。有用な情報を提供することと、あまりにも多くの詳細でユーザーを圧倒することの間には、微妙なバランスを取る必要があります。この機能を開発する際、私たちは追加されたコンテキストがユーザーエクスペリエンスを複雑にするのではなく、向上させるスイートスポットを見つけることに焦点を当てます。

私たちの地平線上で最もエキサイティングな強化は、おそらくAI自動タグ付けと私たちのプロジェクト管理自動化システムとの統合です。

これは、AIタグ付け機能が自動化のトリガーまたはアクションのいずれかになる可能性があることを意味します。これは、このかなりシンプルなAIカテゴリ分類機能を作業のためのAIベースのルーティングシステムに変える可能性があるため、大きな意味を持つ可能性があります。

次のような自動化を想像してください：

AIがレコードを「クリティカル」とタグ付けしたとき -> 「マネージャー」に割り当ててカスタムメールを送信

これは、レコードをAIタグ付けするときに、AIがそれが重要な問題であると判断した場合、プロジェクトマネージャーに自動的に割り当てて、カスタムメールを送信できることを意味します。これにより、プロジェクト管理自動化システムの利点が純粋にルールベースのシステムから真の柔軟なAIシステムに拡張されます。

プロジェクト管理におけるAIの最前線を継続的に探求することで、ユーザーの現在のニーズを満たすだけでなく、仕事の未来を予測し、形作るツールをユーザーに提供することを目指しています。いつものように、私たちはユーザーコミュニティと密接に協力してこれらの機能を開発し、すべての強化がプロジェクト管理プロセスに実際の実用的な価値を追加することを確実にします。

結論

以上です！

これは実装するのが楽しい機能であり、以前にリリースしたAIコンテンツ要約と並んで、AIへの最初のステップの1つでした。AIが将来のプロジェクト管理においてますます大きな役割を果たすことを知っており、高度なLLM（大規模言語モデル）を活用したより革新的な機能をリリースするのが待ちきれません。

これを実装する際に考慮すべきことがかなりありましたが、Blueの既存のプロジェクト管理自動化エンジンと共に、将来この機能をどのように活用できるかについて特に興奮しています。

また、これが興味深い読み物であったことを願っており、毎日使用している機能をどのようにエンジニアリングしているかについての洞察を提供できたことを願っています。

問題