顧客が本番環境の準備ができている場合 インテリジェントなドキュメント処理 (IDP) ワークロードに関して、私たちは Well-Architected レビューのリクエストをよく受け取ります。 エンタープライズ ソリューションを構築するには、望ましいビジネス成果を達成するために、開発者のリソース、コスト、時間、ユーザー エクスペリエンスのバランスを取る必要があります。 の AWS の適切に設計されたフレームワーク クラウド内で信頼性、安全性、効率性、コスト効率に優れ、持続可能なワークロードを設計および運用するための運用およびアーキテクチャのベスト プラクティスを組織が学習するための体系的な方法を提供します。
IDP Well-Architected カスタム レンズは、AWS Well-Architected フレームワークに従い、特定の AI または機械学習 (ML) ユースケースの粒度で XNUMX つの柱でソリューションをレビューし、一般的な課題に取り組むためのガイダンスを提供します。 IDP の適切に設計されたカスタム レンズ 適切に設計されたツール それぞれの柱に関する質問が含まれています。 これらの質問に答えることで、潜在的なリスクを特定し、改善計画に従ってそれらを解決できます。
この投稿では以下に焦点を当てます パフォーマンス効率の柱 IDP ワークロードの。 スループット、レイテンシー、全体的なパフォーマンスを最適化するためのソリューションの設計と実装を深く掘り下げます。 まず、Well-Architected レビューを実施する必要があるいくつかの一般的な指標について説明し、設計原則を伴う基本的なアプローチを紹介します。 次に、各重点領域を技術的な観点から見ていきます。
この投稿を読み進めるには、このシリーズの以前の投稿に精通している必要があります (第1部 および 第2部) とガイドライン AWS でのインテリジェントなドキュメント処理に関するガイダンス。 これらのリソースでは、IDP ワークロード用の一般的な AWS サービスと推奨されるワークフローを紹介します。 この知識があれば、ワークロードの実稼働化について詳しく学ぶ準備が整いました。
共通指標
以下は、パフォーマンス効率の柱に対して適切に設計されたフレームワークのレビューを実施する必要がある一般的な指標です。
- 高遅延 – 光学式文字認識 (OCR)、エンティティ認識、またはエンドツーエンドのワークフローの遅延が以前のベンチマークよりも長い場合、これは、アーキテクチャ設計が負荷テストやエラー処理をカバーしていないことを示している可能性があります。
- 頻繁なスロットリング – 次のような AWS サービスによるスロットリングが発生する場合があります。 アマゾンテキストラック リクエスト制限のため。 これは、アーキテクチャのワークフロー、同期および非同期の実装、XNUMX 秒あたりのトランザクション数 (TPS) の計算などを検討して、アーキテクチャを調整する必要があることを意味します。
- デバッグの難しさ – ドキュメント処理でエラーが発生した場合、エラーがワークフロー内のどこにあるのか、エラーがどのサービスに関連しているのか、エラーが発生した理由を特定する効果的な方法がない場合があります。 これは、システムがログと障害を把握できないことを意味します。 テレメトリ データのログ設計を再検討し、ドキュメント処理パイプラインなどのコードとしてのインフラストラクチャ (IaC) をソリューションに追加することを検討してください。
インジケータ | Description | 建築上のギャップ |
高遅延 | OCR、エンティティ認識、またはエンドツーエンドのワークフローの遅延が以前のベンチマークを超えています |
|
頻繁なスロットリング | リクエスト制限による Amazon Textract などの AWS サービスによるスロットリング |
|
デバッグが難しい | 文書処理の失敗の場所、原因、理由が見えない |
|
設計原則
この投稿では、複雑な AI タスクの委任、IaC アーキテクチャ、サーバーレス アーキテクチャという XNUMX つの設計原則について説明します。 XNUMX つの実装の間でトレードオフが発生した場合は、組織のビジネスの優先順位に合わせて設計原則を再検討し、効果的に意思決定を行うことができます。
- 複雑な AI タスクを委任する – ML モデル開発ライフサイクルをマネージドサービスにオフロードし、AWS が提供するモデル開発とインフラストラクチャを利用することで、組織での AI 導入を迅速化できます。 データ サイエンスと IT チームに AI モデルの構築と維持を要求するのではなく、タスクを自動化できる事前トレーニング済みの AI サービスを使用できます。 これにより、クラウド プロバイダーが AI モデルのトレーニング、デプロイ、スケーリングの複雑さを処理しながら、チームはビジネスを差別化するより価値の高い作業に集中できます。
- IaC アーキテクチャ – IDP ソリューションを実行する場合、ソリューションには、エンドツーエンドのワークフローを時系列に実行するための複数の AI サービスが含まれます。 次を使用して、ワークフロー パイプラインを使用してソリューションを設計できます。 AWSステップ関数 耐障害性、並列処理、可視性、およびスケーラビリティを強化します。 これらの利点により、基盤となる AI サービスの使用量とコストを最適化できます。
- サーバレス アーキテクチャ – IDP は多くの場合、ユーザーのアップロードまたはスケジュールされたジョブによって開始されるイベント駆動型のソリューションです。 このソリューションは、AI サービスの通話レートを上げることで水平方向にスケールアウトできます。 AWSラムダ、およびその他の関連サービス。 サーバーレスのアプローチにより、リソースを過剰にプロビジョニングすることなく拡張性が提供され、不必要な出費が防止されます。 サーバーレス設計の背後にある監視は、パフォーマンスの問題の検出に役立ちます。
これら XNUMX つの設計原則を念頭に置くことで、組織はクラウド プラットフォーム上で AI/ML 導入のための効果的な基盤を確立できます。 複雑さを委任し、回復力のあるインフラストラクチャを実装し、規模に合わせた設計を行うことで、組織は AI/ML ソリューションを最適化できます。
次のセクションでは、技術的に重点を置く領域に関する一般的な課題に対処する方法について説明します。
重点分野
パフォーマンス効率をレビューする際には、アーキテクチャ設計、データ管理、エラー処理、システム監視、モデル監視の XNUMX つの重点領域からソリューションをレビューします。 これらの重点領域を使用すると、さまざまな側面からアーキテクチャのレビューを実施して、AI/ML プロジェクト、データ、モデル、またはビジネス目標の XNUMX つのコンポーネントの有効性、可観測性、拡張性を強化できます。
建築デザイン
この重点領域の質問に答えることで、既存のワークフローをレビューし、ベスト プラクティスに従っているかどうかを確認します。 提案されたワークフローは、組織が従うことができる共通のパターンを提供し、試行錯誤のコストを防ぎます。
に基づく 提案されたアーキテクチャのワークフローは、データの取得、分類、抽出、強化、レビューと検証、使用の XNUMX つの段階に従います。 先ほど説明した一般的な指標では、XNUMX つのうち XNUMX つはアーキテクチャ設計の問題に起因しています。 これは、即席のアプローチでプロジェクトを開始すると、インフラストラクチャをソリューションに合わせようとする際にプロジェクトの制約に遭遇する可能性があるためです。 アーキテクチャ設計のレビューでは、即席の設計を段階として分離し、それぞれを再評価して並べ替えることができます。
導入することで、時間、お金、労力を節約できます 分類 ワークフロー内でドキュメントが作成され、ドキュメントはドキュメント タイプに基づいてダウンストリーム アプリケーションと API に送られます。 これにより、ドキュメント プロセスの可観測性が向上し、新しいドキュメント タイプを追加する際のソリューションの保守が簡単になります。
データ管理
IDP ソリューションのパフォーマンスには、遅延、スループット、エンドツーエンドのユーザー エクスペリエンスが含まれます。 ソリューション内でドキュメントとそこから抽出された情報を管理する方法が、データの一貫性、セキュリティ、プライバシーの鍵となります。 さらに、ソリューションは、低遅延と高スループットで大量のデータを処理する必要があります。
この重点領域の質問に取り組むときは、ドキュメントのワークフローを確認します。 これには、データの取り込み、データの前処理、Amazon Textract で受け入れられるドキュメントタイプへのドキュメントの変換、受信ドキュメントストリームの処理、タイプごとのドキュメントのルーティング、アクセス制御と保持ポリシーの実装が含まれます。
たとえば、ドキュメントをさまざまな処理フェーズに保存することで、必要に応じて前のステップに処理を戻すことができます。 データのライフサイクルにより、ワークロードの信頼性とコンプライアンスが保証されます。 を使用することで、 Amazon Textract サービスのクォータ計算ツール (次のスクリーンショットを参照)、Amazon Textract、Lambda、Step Functions の非同期機能、 Amazon シンプル キュー サービス (Amazon SQS)、および Amazon シンプル通知サービス (Amazon SNS) を使用すると、組織はドキュメント処理タスクを自動化および拡張して、特定のワークロードのニーズを満たすことができます。
エラー処理
堅牢なエラー処理は、ドキュメントの処理ステータスを追跡するために重要であり、これにより、運用チームは、予期しないドキュメントの量、新しいドキュメントの種類、サードパーティ サービスからのその他の計画外の問題など、異常な動作に対応する時間を確保できます。 組織の観点から見ると、適切なエラー処理によりシステムの稼働時間とパフォーマンスが向上します。
エラー処理は、次の XNUMX つの主要な側面に分類できます。
- AWSのサービス構成 – 指数バックオフを使用した再試行ロジックを実装して、スロットリングなどの一時的なエラーを処理できます。 次のような非同期 Start* オペレーションを呼び出して処理を開始するとき startdocumentTextDetectionでは、リクエストの完了ステータスを SNS トピックに公開するように指定できます。 通知チャネル 構成。 これにより、Get* API のポーリングによる API 呼び出しのスロットル制限を回避できます。 アラームを実装することもできます アマゾンクラウドウォッチ 異常なエラーの急増が発生した場合にアラートをトリガーします。
- エラーレポートの機能強化 – これには、エラー タイプ別の適切な詳細レベルの詳細メッセージとエラー処理応答の説明が含まれます。 適切なエラー処理設定を行うと、断続的なエラーの自動再試行、サーキット ブレーカーを使用したカスケード障害の処理、サービスの監視によるエラーの洞察の獲得などの一般的なパターンを実装することで、システムの回復力を高めることができます。 これにより、ソリューションは再試行制限の間でバランスをとることができ、終わりのない回線ループを防ぐことができます。
モデル監視
ML モデルのパフォーマンスは、時間の経過とともに低下するかどうか監視されます。 データとシステムの状態が変化すると、モデルのパフォーマンスと効率のメトリクスが追跡され、必要に応じて再トレーニングが実行されるようになります。
IDP ワークフローの ML モデルは、OCR モデル、エンティティ認識モデル、または分類モデルにすることができます。 モデルは AWS AI サービス、つまり AWS のオープンソース モデルから取得できます。 アマゾンセージメーカー, アマゾンの岩盤、またはその他のサードパーティのサービス。 人間のフィードバックによってモデルを改善し、時間の経過とともにサービスのパフォーマンスを向上させる方法を特定するには、各サービスの制限とユースケースを理解する必要があります。
一般的なアプローチは、サービス ログを使用してさまざまなレベルの精度を理解することです。 これらのログは、データ サイエンス チームがモデルの再トレーニングの必要性を特定し、理解するのに役立ちます。 組織は再トレーニングのメカニズムを選択できます。再トレーニングのメカニズムは、四半期ごと、毎月、または精度が所定のしきい値を下回った場合などの科学指標に基づくことができます。
モニタリングの目的は、問題を検出するだけではなく、ループを閉じてモデルを継続的に改良し、外部環境の進化に合わせて IDP ソリューションのパフォーマンスを維持することです。
システム監視
IDP ソリューションを実稼働環境に導入した後は、主要なメトリクスと自動化パフォーマンスを監視して、改善の余地がある領域を特定することが重要です。 指標には、ビジネス指標と技術指標を含める必要があります。 これにより、企業はシステムのパフォーマンスを評価し、問題を特定し、モデル、ルール、ワークフローを時間の経過とともに改善して自動化率を高め、運用への影響を理解することができます。
ビジネス面では、重要なフィールドの抽出精度、人間の介入なしで処理されるドキュメントの割合を示す全体的な自動化率、ドキュメントごとの平均処理時間などの指標が最も重要です。 これらのビジネス指標は、エンドユーザー エクスペリエンスと運用効率の向上を定量化するのに役立ちます。
ワークフロー全体で発生するエラー率や例外率などの技術指標は、エンジニアリングの観点から追跡することが不可欠です。 技術的なメトリクスは、エンドツーエンドの各レベルで監視することもでき、複雑なワークロードの包括的なビューを提供します。 メトリックは、ソリューション レベル、エンドツーエンド ワークフロー レベル、ドキュメント タイプ レベル、ドキュメント レベル、エンティティ認識レベル、OCR レベルなどのさまざまなレベルに分類できます。
この柱のすべての質問を確認したので、他の柱を評価し、IDP ワークロードの改善計画を作成できます。
まとめ
この投稿では、IDP ワークロードのパフォーマンス効率の柱について Well-Architected フレームワークのレビューを実行する必要がある可能性がある一般的な指標について説明しました。 次に、設計原則を順を追って概要を説明し、ソリューションの目標について説明しました。 IDP Well-Architected Custom Lens を参照してこれらの提案に従い、重点分野ごとに質問を確認することで、プロジェクトの改善計画が作成できるはずです。
著者について
ミア・チャン は、アマゾン ウェブ サービスの ML スペシャリスト ソリューション アーキテクトです。 彼女は EMEA の顧客と協力し、応用数学、コンピューター サイエンス、AI/ML のバックグラウンドを活かして、クラウド上で AI/ML ワークロードを実行するためのベスト プラクティスを共有しています。 彼女は NLP 固有のワークロードに焦点を当てており、カンファレンスの講演者および本の著者としての経験を共有しています。 自由時間には、ハイキング、ボードゲーム、コーヒー淹れを楽しんでいます。
ブリジェシュ・パティ AWS のエンタープライズ ソリューション アーキテクトです。 彼の主な焦点は、企業顧客がワークロードにクラウド テクノロジーを導入できるよう支援することです。 彼はアプリケーション開発とエンタープライズ アーキテクチャの経験があり、スポーツ、金融、エネルギー、プロフェッショナル サービスなど、さまざまな業界の顧客と協力してきました。 彼の興味はサーバーレス アーキテクチャと AI/ML です。
ルイ・カルドーソ は、アマゾン ウェブ サービス (AWS) のパートナー ソリューション アーキテクトです。 AI/ML と IoT に焦点を当てています。 彼は AWS パートナーと協力し、AWS でのソリューションの開発をサポートしています。 仕事以外のときは、サイクリングやハイキングを楽しんだり、新しいことを学んだりしています。
ティム・コンデロ は、アマゾン ウェブ サービス (AWS) のシニア人工知能 (AI) および機械学習 (ML) スペシャリスト ソリューション アーキテクトです。 彼の焦点は自然言語処理とコンピューター ビジョンです。 ティムは、顧客のアイデアを取り入れて、拡張可能なソリューションに変えることを楽しんでいます。
シェリー・ディン は、アマゾン ウェブ サービス (AWS) のシニア人工知能 (AI) および機械学習 (ML) スペシャリスト ソリューション アーキテクトです。 彼女は機械学習に関して豊富な経験を持ち、コンピューター サイエンスの博士号を取得しています。 彼女は主に公共部門の顧客と協力して AI/ML 関連のさまざまなビジネス課題に取り組み、AWS クラウドでの機械学習の取り組みを加速できるよう支援しています。 顧客をサポートしていないときは、屋外アクティビティを楽しんでいます。
ワン・スイン AWS の AI/ML スペシャリスト ソリューション アーキテクトです。 彼女は、機械学習、金融情報サービス、経済学の学際的な教育背景を持ち、現実世界のビジネス上の問題を解決するデータ サイエンスおよび機械学習アプリケーションの構築に長年の経験を持っています。 彼女は、顧客が適切なビジネス上の質問を特定できるよう支援し、適切な AI/ML ソリューションを構築することに喜びを感じています。 余暇には、歌うことと料理が大好きです。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
- プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
- プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
- プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
- 情報源: https://aws.amazon.com/blogs/machine-learning/build-well-architected-idp-solutions-with-a-custom-lens-part-4-performance-efficiency/
- :持っている
- :は
- :not
- :どこ
- 1
- 10
- 100
- 32
- 7
- 8
- a
- 私たちについて
- 加速する
- 一般に認められた
- アクセス
- 精度
- 達成する
- 活動
- 追加
- さらに
- 住所
- 調整
- 採用
- 養子縁組
- 利点
- 利点
- AI
- AIモデル
- AIサービス
- AI / ML
- 警告
- 整列する
- すべて
- ことができます
- 沿って
- また
- Amazon
- アマゾンテキストラック
- Amazon Webサービス
- Amazon Webサービス(AWS)
- an
- および
- とインフラ
- どれか
- API
- API
- 申し込み
- アプリケーション開発
- 適用された
- 適用
- アプローチ
- アプローチ
- 適切な
- 建築の
- 建築
- です
- AREA
- エリア
- 人工の
- 人工知能
- 人工知能(AI)
- AS
- 側面
- 評価する
- アシスト
- At
- 著者
- 自動化する
- 自動的に
- オートメーション
- 平均
- 避ける
- AWS
- 背景
- ベース
- BE
- なぜなら
- 行動
- 背後に
- 以下
- ベンチマーク
- 恩恵
- BEST
- ベストプラクティス
- の間に
- ボード
- ボードゲーム
- 本
- ブレーク
- ビルド
- 建物
- ビジネス
- 焙煎が極度に未発達や過発達のコーヒーにて、クロロゲン酸の味わいへの影響は強くなり、金属を思わせる味わいと乾いたマウスフィールを感じさせます。
- by
- 計算
- コール
- 呼び出し
- コール
- 缶
- キャプチャー
- 場合
- 例
- 原因となる
- 課題
- 変化する
- 文字
- 文字認識
- 選択する
- 分類
- 閉鎖
- クラウド
- コード
- コーヒー
- 来ます
- コマンドと
- 会社
- 完成
- 複雑な
- 複雑さ
- コンプライアンス
- コンポーネント
- 包括的な
- コンピュータ
- コンピュータサイエンス
- Computer Vision
- 条件
- プロフェッショナルな方法で
- 講演
- 検討
- 消費
- 含まれています
- 連続的に
- コントロール
- 変換
- 費用
- コスト効率の良い
- コスト
- カバー
- 重大な
- カスタム
- 顧客
- Customers
- データ
- データ管理
- データサイエンス
- 決定
- 分離された
- 深いです
- 度
- 展開します
- 展開する
- 設計
- 設計原理
- 設計
- 希望
- 詳細
- 詳細な
- 開発する
- Developer
- 開発
- 開発
- 異なります
- 困難
- 話し合います
- 議論する
- 議論
- ダイビング
- ドキュメント
- 文書処理
- ドキュメント
- そうではありません
- ダウン
- ドロップス
- 原因
- 各
- 前
- Economics
- 教育
- 効果的な
- 効果的に
- 効率
- 効率的な
- EMEA
- enable
- end
- 端から端まで
- エネルギー
- エンジニアリング
- 高めます
- 強化
- 充実
- 確保
- 確実に
- Enterprise
- エンティティ
- 環境
- エラー
- エラー
- 本質的な
- 確立する
- 評価する
- 進化する
- 例
- 超え
- 例外
- 既存の
- 経費
- 体験
- 指数関数
- 広範囲
- 豊富な経験
- 外部
- 抽出
- 不良解析
- 障害
- おなじみの
- 速いです
- 特徴
- フィードバック
- フィールズ
- フィギュア
- ファイナンス
- ファイナンシャル
- 財務情報
- 五
- フォーカス
- 焦点を当てて
- 焦点
- フォロー中
- 次
- Foundation
- フレームワーク
- 無料版
- から
- 機能
- 基本的な
- 利得
- 利益
- Games
- 与えられた
- Go
- 目標
- 行く
- ガイダンス
- ガイドライン
- ハンドル
- ハンドル
- ハンドリング
- 持ってる
- he
- 助けます
- 助け
- ことができます
- 彼女の
- ハイ
- ハイレベル
- 彼の
- 水平に
- 認定条件
- How To
- HTML
- HTTP
- HTTPS
- 人間
- 考え
- 識別する
- if
- 影響
- 実装する
- 実装
- 実装
- 実装
- 重要
- 改善します
- 改善
- 改善
- in
- include
- 含ま
- 含めて
- 入ってくる
- 増える
- の増加
- インジケータ
- インジケータ
- 産業
- 情報
- インフラ関連事業
- 開始
- 洞察力
- インテリジェンス
- インテリジェント-
- インテリジェントなドキュメント処理
- 利益
- 介入
- に
- 紹介する
- 関係する
- IOT
- 問題
- IT
- ITS
- Jobs > Create New Job
- 旅
- JPG
- ただ
- キープ
- キー
- 知識
- 労働
- 言語
- レイテンシ
- LEARN
- 学習
- レベル
- レベル
- wifecycwe
- ような
- 制限
- 制限
- 負荷
- 位置して
- 場所
- ロギング
- ロジック
- より長いです
- で
- ロー
- 機械
- 機械学習
- 主に
- 維持する
- make
- 作る
- 管理します
- マネージド
- 管理
- 数学
- 五月..
- 手段
- 大会
- メッセージ
- メトリック
- マインド
- ML
- モデル
- お金
- モニター
- 監視対象
- モニタリング
- monthly
- 他には?
- の試合に
- しなければなりません
- ナチュラル
- 自然言語処理
- 必要
- 必要とされる
- ニーズ
- 新作
- 通知
- 今
- 発生した
- 発生する
- OCR
- of
- 頻繁に
- on
- 開いた
- オープンソース
- オペレーティング
- 操作
- オペレーショナル
- 光学式文字認識
- 最適化
- or
- 注文
- 組織
- 組織
- その他
- でる
- 結果
- が
- 全体
- 概要
- 並列シミュレーションの設定
- 最高の
- 部
- パートナー
- パートナー
- パターン
- パターン
- 以下のために
- 割合
- 実行する
- パフォーマンス
- 実行
- 実行
- 視点
- 博士号
- 柱
- 柱
- 計画
- プラットフォーム
- プラトン
- プラトンデータインテリジェンス
- プラトデータ
- ポリシー
- ポスト
- 投稿
- 潜在的な
- プラクティス
- 予防
- を防止
- 前
- 主要な
- 原則
- プライバシー
- 問題
- プロセス
- 処理済み
- 処理
- 生産
- プロ
- プロジェクト
- 適切な
- 提供します
- 提供
- プロバイダー
- は、大阪で
- 提供
- 公共
- 公表
- 質問
- レート
- 価格表
- むしろ
- 反応する
- 準備
- 現実の世界
- 理由
- 受け取ります
- 認識
- 参照
- リファイン
- に対する
- よろしく
- 関連する
- 信頼性
- 信頼性のある
- レポート
- 要求
- リクエスト
- 弾力性のあります
- 解決する
- リソース
- 回答
- 保持
- 逆
- レビュー
- 日
- レビュー
- 右
- リスク
- ルーティング
- ルール
- ランニング
- Save
- スケーラビリティ
- ド電源のデ
- 規模
- スケーリング
- 予定の
- スケジュールされたジョブ
- 科学
- 二番
- セクション
- セクター
- 安全に
- セキュリティ
- シニア
- シリーズ
- サーバレス
- サービス
- サービス
- 株式
- 彼女
- すべき
- 側
- 簡単な拡張で
- SIX
- So
- 溶液
- ソリューション
- 一部
- ソース
- スピーカー
- 専門家
- 特定の
- スパイク
- スポーツ
- ステージ
- start
- Status:
- 手順
- 保存
- 簡単な
- ストリーム
- そのような
- サポート
- 持続可能な
- システム
- タックル
- 取り
- 取得
- タスク
- チーム
- チーム
- 技術的
- テクノロジー
- テスト
- より
- それ
- アプリ環境に合わせて
- それら
- その後
- ボーマン
- 物事
- サードパーティ
- この
- 三
- しきい値
- 介して
- 全体
- スループット
- ティム
- 時間
- 〜へ
- 公差
- トピック
- TPS
- 追跡する
- 追跡
- トレーニング
- 取引
- しよう
- ターニング
- 2
- type
- 根本的な
- わかる
- 予期しない
- 不要
- uptime
- 使用法
- つかいます
- 使用事例
- ユーザー
- 操作方法
- さまざまな
- 詳しく見る
- 視認性
- ビジョン
- ボリューム
- vs
- walked
- 仕方..
- 方法
- we
- ウェブ
- Webサービス
- いつ
- which
- while
- なぜ
- 意志
- 無し
- 仕事
- 働いていました
- ワークフロー
- ワークフロー
- ワーキング
- 作品
- 年
- You
- あなたの
- ゼファーネット