マッチングアプリ「タップル」のiOS開発を担当している横山です。
本記事では、Foundation ModelsをはじめとしたオンデバイスAIによる投稿前警告と、WWDC2026にて発表されたSiri AIによる新しい体験についてご紹介します。
投稿前警告は、写真や自己紹介文を投稿する前に端末の中で確かめ、審査に通らない可能性があればその場でお知らせするものです。警告を見たユーザーの約半数が、自分で投稿を差し替えました。
Siri AIとの連携は、話しかけた言葉をそのままアプリに渡して、趣味タグを検索できるようにしたものです。
ビジネスリードエンジニア（BLE）とは
サイバーエージェントは2026年8月、AI時代の新たなエンジニア職種として「ビジネスリードエンジニア（以下 BLE）」を新設しました。
総合的な技術力を基盤に、事業やプロダクトの現場へ深く関与し、課題発見・要件定義・設計・実装・運用までを一気通貫で担うことで、ビジネスインパクトを創出するエンジニア
— AI時代の新たなエンジニア職種「ビジネスリードエンジニア（BLE）」を新設
どういう働き方なのかは、先にBLEとして紹介された2人の記事が分かりやすいです。技術の鋭さとビジネスの解像度を併せ持つ。「値引き革命」に挑む、ビジネスリードエンジニアの真価、専門性があるからこそ、切り拓けるフロンティアがある。データサイエンスとビジネスの境界を越える、「ビジネスリードエンジニア」の歩み。
私自身はビジネスリードエンジニアとして、タップルのiOSを担当しています。
まだ手探りではありますが、iOSが持つ豊富なフレームワークやそのAPIを用いて今まで検討もできなかった領域に対して新しい価値を提供することに重きを置いて従事しています。
投稿前の警告 — オンデバイスAIで、否認される前に気づいてもらう
タップルでは、安心安全にご利用いただくために、24時間365日、オペレーターが監視をしています。その対象には、画像や自己紹介等のテキストも含まれます。実際の数は伏せますが、1日あたりの監視件数の総数は膨大です。
タップルでは、全ての会員が安心・安全にご利用いただけるよう、下記のような取り組みを行っています。
24時間365日、オペレーターが監視を行い会員の安全をお守りいたします。
・プロフィール画像、趣味画像のチェック
・悪質な会員の監視・強制退会
・不快な文章の削除
・公序良俗に反する内容の削除利用制限・投稿制限を設けることで、あなたに安心してご利用いただけるサービス運営を行っています。
監視結果が返ってくるのは、投稿の後です。意図せず含めてしまった要素で否認されれば、ユーザーの体験を損ないます。投稿前に気づいていれば、その投稿にかかった監視オペレーションも発生しませんでした。
この課題に対する解決策が、オンデバイスAIや機械学習APIによる検知と警告です。
Appleが提供しているオンデバイスAIや機械学習APIは「AIと機械学習」にまとまっており、その用途や種類は多岐にわたります。今回採用したものはいずれも端末の中で完結するため、ランニングコストやプライバシーの観点から見ても高い利点があります。本記事では採用した代表例を3つ紹介します。
写真が基準に合わない — Visionフレームワーク
メイン写真であれば、
– 画素数が低く、画像が不鮮明なもの
– 写っている人物の顔を認識できないもの（顔の半分以上確認できないもの、目元が確認できないもの、など）
といった理由などがあります。その他の例はメイン写真が否認されるのはなぜですか？をご覧ください。
– 画像内のテキストを認識する RecognizeTextRequest
– 顔写真を光量や鮮明度合い、顔の位置から品質を判断する DetectFaceCaptureQualityRequest
などが搭載されています。これらのAPIを用いて、画像が不鮮明なものと、顔を認識できないものを投稿前に検知できるようにしました。本人確認書類の写りが不鮮明のため確認できませんや上記に挙がっている理由のうちの一部にあたります。
動画に意図しない音楽が入る — Sound Analysisフレームワーク
タップルにはプロフィールに動画を設定できる機能があります。動画プロフィールは画像に比べて多くの表現ができる一方で、より多角的に監視することが求められます（動画プロフィールが否認されるのはなぜですか？）。中でも、被写体とは異なる要素として音楽・楽曲を意図せず含めてしまったケースは容易に考えられます。
iOSのBuild In Sound Analysisを使った音声認識で著作権侵害を防ぐ！（Yahoo! JAPAN Tech Blog）を参考に、Sound Analysisフレームワークを採用しました。これを用いて、音楽を含む動画を投稿前に検知できるようにしました。上記に挙がっている理由のうちの1つにあたります。
自己紹介文が基準に触れる — Foundation Modelsフレームワーク
写真や動画と違い、自己紹介文の否認理由は数え上げられません。連絡先の記載、勧誘とみなされる表現、他社サービスへの誘導。いずれも文面の組み合わせ次第で判断が変わるため、決まったパターンとして持っておくことができません。
用途に合ったAPIがあるなら、それを使うべきです。無いときにどうするか。その答えがFoundation Modelsフレームワークでした。自己紹介文のような自然言語には強力な手段になります。Natural Languageフレームワークの sentimentScoreも検討しましたが、具体的な監視基準には不十分で、LLMを採用しました。
Siri AI との連携 — 趣味タグを言葉で探してもらう
Siri AI とは
2026年9月14日、Appleは次世代のApple Intelligenceを提供開始しました。
Siri AIは、完全に生まれ変わったバージョンのSiriとして、よりパーソナルでパワフル
日本語については「10月より、フランス語、韓国語、ポルトガル語、スペイン語に加えて日本語でもベータ版で提供開始」とされています。
ここで押さえておきたいのは、アプリは何もしなければSiri AIの対象にならないということです。Human Interface Guidelinesにこう書かれています。
デフォルトでは、システムはアプリが実行できることおよびアプリに含まれる情報を具体的に認識していません。アプリをSiriと連携させるには、アプリでApp Intentsフレームワークを使用して、アプリの機能とコンテンツをApple Intelligenceで利用可能にする必要があります。
その公開に必要なのはSchemaへの準拠です。
スキーマはアプリとシステム間の契約として機能し、Apple Intelligenceはこれをアクションとコンテンツの識別、クエリ、理解に用います。
Siri AIはスキーマを使用して、アクションとコンテンツを人々が日常会話で話すフレーズに対応させます。
その他、Schemaだけではなく、Spotlightへの索引付けや、アプリの行動をシステムに伝えるdonationも重要です。
アクションやコンテンツを提供すると、Apple Intelligenceはそれを行動の手がかりとして、トレンドの特定、将来の行動の予測、あいまいなリクエストの明確化に役立てます。
Siri AIから趣味タグを検索
スキーマのドメインはApp schema domainsで公開されています。このうちPrimary domainsかShortcuts-specific domainsに準拠させることで、Siri AIから扱えます。ただしPrimary domainsはAudio、Calendar、Mail、Maps、Messages、Photosといった顔ぶれです。タップルが提供する機能に合うSchemaは数少なく、適用自体も難しいことが分かりました。
そこで、現時点での最適解として System and in-app search による趣味タグ検索を選択しました。
Siri AIとの会話から、キーワードをアプリ側に渡しつつ立ち上げて検索する様式です。
異なるサポートOSや端末を吸収するアーキテクチャ戦略
ここまでの2つは、要求するOSや端末がばらばらです。VisionのSwift版APIはiOS 18以上、Foundation Modelsフレームワークは iOS 26以上に加えて端末と設定の条件があり、App IntentsによるSiri AIとの連携も iOS 26以上です。一方、タップルは2026年9月現在 iOS 17.0以上をサポートしています。
呼び出し側がこの差分を意識すると、画面ごとに分岐が散ります。使えるか使えないかの判定があちこちに増え、どこで何を出し分けているのかを追えなくなります。
iOSのタップルでは、View層・Presenter層・Service層・Manager層といったレイヤードアーキテクチャを採用しています。依存解決にはswift-dependenciesを使っています。この形を活かして、OSや端末の差分をManager層に閉じ込めました。Presenterは、使えるなら結果が返り、使えないなら返らない、とだけ知っていれば済みます。新しいAPIを足すときも、触るのはManager層だけです。
同じ形は他の領域でも採っています。詳しくは新旧MetricKitの共存 – iOS 27を見据えたタップルの戦略をご覧ください。
技術への解釈を揃える社内ガイドライン
タップルは安心安全について、数多くの記事を公開しています。マッチングアプリをさらに社会に信頼される存在へ。タップルが安心安全に本気で向き合う理由、わたしたちの取り組み。また、「タップルAI」構想も公開しています。これらに加えて、Human Interface Guidelinesの「生成AI」も組み込みつつ、再現性の高いレギュレーションを固める必要がありました。なぜなら、いずれもタップルにおいてはこれまで使っていない技術であり、ユーザー体験に直結するからです。扱うデータもプライバシーに関わるものです。そのため、新機能のたびにステークホルダーとすり合わせるのでは、リードタイムが延びてしまいます。機能によって解釈が異なってしまうリスクもあります。そこで、法務を含めたステークホルダーとの協議を私が取りまとめ、技術に対する解釈を揃えた社内ガイドラインを整備しました。
課題そのものは、以前から社内にあったものです。そこにどの技術が使えるかを結びつけ、解釈を揃えて合意まで持っていく。BLEとして担ったのは、この部分でした。
以下ガイドラインの抜粋です。
意思決定の主導権をユーザーに残すこと
Human Interface Guidelinesには、こう記されています。
AIはコンテンツの作成や操作を行えますが、ユーザの主体性を尊重し、意思決定や全体的な体験に関する主導権が必ずユーザ側に残るようにしましょう。ユーザのリクエストが対応できる範囲内であり、期待される出力が明確な場合はそれを尊重し、センシティブな内容の場合は慎重に対応してください。
こちらに則り、承認される可能性が低いと判断したとしても、ユーザーの投稿そのものをブロックするのではなく、あくまで可能性を伝えるに留めています。また、個人情報等の利用についてにもオンデバイスに関する記述を追記しました。
該当の機能が使えないOSや端末を考慮すること
Human Interface Guidelinesには、こう記されています。
特定の体験では生成AIが不可欠で、AI以外に現実的な代替手段が存在しない場合もあります。一方で、AIがアプリの基本機能を強化する補完的な役割を果たすものの、AIを利用できなくてもユーザの目的達成には支障ない場合もあります。
前述のとおり、採用したAPIは要求するOSや端末が異なります。該当機能を使えないユーザーは多数存在します。そのため、要求の高いAPIを採用する場合でも、その一部を代替できるのであれば、広く使えるAPIを用いることを原則としました。AIが使えない端末でも、投稿はこれまでどおり成立します。
最後に
詳細な数値は控えますが、Sound Analysisフレームワークによる音声検知では、導入前後で否認数が大きく減少しました。それだけ意図せず含めていたということを推測しています。また、既存オペレーションによる否認数も全体的に減少しました。これらの結果から、タップルとしての承認数は変わらずに、投稿数に対する否認数の割合を減少させることができました。
サービスとしての結果は上記ですが、前述したガイドラインを中心に社内への浸透・文化醸成も合わせて実施してきました。その結果として、「タップルサポートAI」というチャットボット形式の機能がリリースされました。
このように、未使用な技術による新たな可能性を探り、浸透・文化醸成と並行しながら、最初の事例を示す。その後、タップルとして再現性の高い形に昇華できるようにサポートする。以上のような経緯を踏まえて、オンデバイスAIとSiri AIによる新しい価値の創出を、ビジネスリードエンジニアとして推進しています。