本記事はわた推し～AWSアワードエンジニア編～ 3日目の記事です。
💻 2日目 ▶▶ 本記事 ▶▶ 4日目 💻

　佐々木拓郎です。
2019年以来選出されているAWS Partner Ambassadorに今年も選ばれました。併せてTop Engineersにも選出されています。ALL Certificate Engineersも取れる状況だったのですが、応募が別口で必要と知らずに惜しくも落選（応募していない）しました。関係者の皆様、私の本を買っていただいた皆様のお陰です。ありがとうございます
　というところで、NRIネットコム、2022 Japan APN Ambassadors / Top Engineers / ALL Certificate Engineers による推しテクシリーズです。何について語ろうかと思い呟いたところ、マニアックなAWSサービス挙げれるか選手権が開催されてしまいました。

推しのAWSサービスって何だろう？
IAMは推しじゃなくて、必要だから使っている。やっぱりS3とかSQSとか古いの出てくるけど、最近のサービスに追随できていないからか
せっかくなので、マニアックな路線でいってみるか。その辺歩いているAWSエンジニア捕まえた時に100人聞いて3人くらいしか知らないやつ
— Takuro SASAKI (@dkfj) 2022年6月16日

その流れに沿って、マニアックなサービスを推していこうと思います。今回私が推すサービスは、Amazon Mechanical Turkです。

Amazon Mechanical Turkって何？　群衆のクラウド

　Mechanical Turk（メカニカルターク）は、APIを通じてクラウドソーシングするサービスです。Mechanical Turkのワーカー登録した人が何万人といて、画像の判別や分類といったタスクや、あるいは説明文を書くといったようなタスクを依頼することができます。ワーカーの人は、気に入ったタスクを選び完了すると報酬を得られます。
　サービスの語源は、The Turk・トルコ人 (人形)です。これは18世紀後半にチェスを指す人形として興行に使われていたそうです。人形がチェスを指しているように見えるけど、中に人間が入っていて人形を操りながらチェスを指していたというオチです。これを面白がって再現したのが、Amazon Mechanical Turkです。プログラムで答えてくれるけど裏には人間がいるというサービスで、The Turkそのものですよね。AWSも上手いこと考えたなぁと思います。

　クラウドソーシング（crowdsourcing）のクラウドは雲（cloud）ではなく群衆（crowd）を意味します。2005年に提供開始したサービスで、AWSの中でも2～3番目に古いサービスです。クラウド（Cloud）上に構築されたクラウド（Crowd）を活用するサービスというダブルミーニングなところがお気に入りの理由です。Crowd in the Cloudですね。なお、AWSの歴史の詳細についてはAWS考古学者の小西さんの記事を読んでみてください。

門前雀羅化するMechanical Turkと、その復権

　2004年と古くからあるMechanical Turkですが、殆どの人が知らないという現状が表すように、それほどメジャーなサービスではありません。2015年のre:Inventに参加した時、100を優に超えるセッションがあるなかでMechanical Turkに関して言及していたのは、私が知る限りサードパーティのテスト会社による１社のみでした。E2EテストにMechanical Turkを組み込むという内容でなかなか面白かったが、全体としてはAWS公式のセッションすらなく寂しい状況でした。

継続的QAの話を聞いている。RainForestという会社のQAサービスだけど、自動化だけでなくMechanical Turkを使っての人力テストをやっているらしい。50,000人以上の参加者とか。その構想考えたことあったけど、英語圏じゃないと厳しいよなぁ
— Takuro SASAKI (@dkfj) 2015年10月9日

　そのような感じで、AWSの本流から少し外れた状態でしたが、2018年くらいを境に一気に復権する流れがありました。機械学習サービスの進展に伴い、データの分類やタグ付けなどアノテーションの作業の部分で、人力を必要としやすい状況になります。そこで脚光を浴びたのがMechanical Turkです。事実2018年のre:Inventでは、AWSによるサービス説明のセッションの他に、ユーザー企業による機械学習のセッションでMechanical Turkを使った事例が幾つか紹介されるようになりました。私が調べた中では、ざっと10くらいのセッションで言及されていました。Mechanical Turkファンとしては嬉しい限りです。（現地では聞いていませんでしたが）

reInventのセッションを物色中。
AIの時代になって、再びMechanical Turkが復権するのか。胸熱
AIM353 - Gathering Data with Amazon Mechanical Turk
— Takuro SASAKI (@dkfj) 2018年10月11日

Mechanical Turkのアーキテクチャの考え方

　蘊蓄ばかり続いたので、ではアーキテクチャとしてはどういった形になるのか簡単に紹介しておきます。Mechanical Turkのサービスの肝は、システムに人の活動を組み込めることにあります。ただし、ミリ秒くらいで作業を完了するコンピュータと、完了まで数分～日単位の時間が掛かる人間の作業を同列で扱うことはできません。そこで重要になるのがワークフローの機能です。システムがリクエストを出して、人が処理をするまでフローを待つといった機能ですね。初期の実装としては、そこにキューサービスであるSQSが使われていました。
　2004年にSQSが出て、2005年に Mechanical Turkという流れをみると、AWSの考え方が垣間見れますね。その後、2012年にワークフロー（SWF）が登場し、それと組み合わせるのが鉄板になります。ただSWFは中々使うのが難しいサービスですので、現時点では視覚的にワークフローを作れるStep Functionsを使うと良いです。（Step Functionsの裏はSWFが動いています）それ以外にも機械学習のサービスであるSage Makerと組み合わせることも増えているようです。

まとめ

　古参だけど知名度が低いMechanical Turkの紹介でした。まとめると次の3点です。

Mechanical Turkはクラウドソーシングのサービス
システムの中に人間の作業・知恵を組み込めるのが売り
組み込む際はワークフローのサービス（Step Functions）を使うのが吉

　人手を組み込めるとなると、システムで出来ることの幅が格段に広がります。たった一人しかいない会社でも、Mechanical Turkにワーカー登録している何万もの人を使ってサービスを提供することができます。従来から人手部分を外部にアウトソースするということはありましたが、その状況を管理する負荷が高く実現が困難な事が多かったです。これをシステムの力でワークフロー化することにより、大部分を自動化できるようになります。夢が広がりますよね。これを読んだ皆さんも是非、自分の考えたサービスを妄想してください。
　ただ実際には組み込むためには、英語圏の人しかいないとか、クオリティの確保の仕組みなどいろいろ検討は必要です。今回は概念の話だけだったので、どこかで具体的なアーキテクチャや実装例を紹介したいと思います。そのためにも、是非ブックマークやTweetでコメントなどの反応をお願いします。