みなさんはWebサイト、Webアプリのパフォーマンスは気にしていますか？

「ある程度遅くなければいいかな」「そんなに影響ないだろう」

と軽視していると、知らない間に顧客を逃すことに繋がり兼ねません。

 

今回はページのパフォーマンスが与える影響、そしてパフォーマンスを上げる技術をご紹介していきます。

 

1. パフォーマンスの影響

読み込み速度の違いが顧客の動きに如何に影響を及ぼすか、調査してみました

以下に2つご紹介します。

◼︎Think with Google

(出典)

Think with Google

上記はGoogleが調査したものですが、ページ離脱率の「増加率」が4パターン表示されています。

例). 読み込み1秒で100人離脱するとした場合

読み込み3秒 … 132人離脱

読み込み5秒 … 190人離脱

読み込み6秒 … 206人離脱

読み込み10秒 … 223人離脱

 

◼︎Reffine

(出典)

Reffine

上記はReffine社より、読み込み速度と離脱率の相関グラフです。

横軸が読み込み時間 (秒)、縦軸が離脱率 (%) になっています。

 

また、世界の企業の成功例もいくつか紹介されていましたので、日本語訳して掲載します。

・ルノーの例

「世界最大級の自動車メーカーであるルノーが、ウェブサイトパフォーマンスの最適化に着手したところ、劇的な成果が得られました。

最大のページ要素の読み込みに必要な時間を1秒未満に短縮したことで、離脱率が14%低下しました。同時に、ルノーではコンバージョンが13%増加し、この相関関係がビジネスの成功に直結することを実証しました。」

・エコノミックタイムズの例

「インドにとどまるエコノミック・タイムズ紙は、毎月4,500万人以上のユニーク・オーディエンスにビジネス志向のニュースを報道している。しかし、同社のウェブサイトはレスポンスに問題を抱えていました。

この問題に対処し、ウェブサイトの平均ページ速度を改善することで、同紙は読み込み時間を80％短縮することに成功しました。この結果、離脱率が43%低下し、ページスピードが再びユーザーの維持に一役買うことになりました。」

 

2. パフォーマンスを測る方法

ここまで読んでくださった方、ご自身や会社のサービスがどのくらいのパフォーマンスなのか、気になっているかと思います。

Google提供で、URLを入力するだけで誰でもパフォーマンスを測定できるページがありますのでご紹介します。

https://pagespeed.web.dev/

サンプルとして試しに松山市のサイトを測ってみました。

結果が以下です。

 

上記のようにモバイル表示とPC表示それぞれでスコアを出すことができます。

 

パフォーマンス：Googleからの総合評価スコアです。0〜100で判定され、90以上だと緑色になります。

First Contentful Paint：最初にテキストや画像が表示されるまでの時間

Largest Contentful Paint：最大サイズのコンテンツが表示されるまでの時間

Total Blocking Time：ユーザー操作が効くようになるまでの時間

Cumulative Layout Shift：突然のレイアウト変更 (例えば画像の読み込み遅れによるテキストの位置変動など) による不安定さ

Speed Index：テキストや画像がすべて表示されるまでの時間

 

ページの単純な読み込み速度は、左下の「Speed Index」に当てはまるかと思います。

 

3. パフォーマンスを最適化する方法

ページの読み込み速度を向上させるためには、以下のような方法や技術を使用することが効果的です。

◼︎画像の最適化

画像はWebページのデータの大部分を占めることが多いため、これを最適化することが重要です。具体例を挙げます。

・圧縮ツール（例えば、TinyPNGやCompressor.io）を使って画像のファイルサイズを削減する。

・写真にはJPEG、透明な画像にはPNGを使用するなど、適切なフォーマットを意識し、WebPなどの次世代フォーマットも検討する。

・自動的に最適化してくれるWebフレームワークを使用する。

例) … Next.jsのnext/imageコンポーネント、Gatsby.jsのgatsby-imageプラグイン、Nuxt.jsの@nuxt/imageモジュール

◼︎ブラウザキャッシングの活用

ブラウザキャッシングを利用すると、ユーザーが再度ページを訪れたときに、以前ロードしたリソースを再ダウンロードせずに済むため、ページの読み込み速度が向上します。

◼︎サーバー応答時間の短縮

サーバー設定を最適化したり、高速なホスティングサービスを選択するなど。

また、サーバーキャッシングやDBのクエリの最適化も有効です。

◼︎SSR (サーバーサイドレンダリング)

クライアントサイドレンダリング（CSR）では、ブラウザがJavaScriptを解析してHTMLを生成しますが、SSRではWebページのHTMLがサーバー側で生成されてブラウザに送信されるため、初回のページ表示が迅速になります。

SSR採用例

… Nuxt.js (デフォルト)、Next.js (デフォルト)、Angular (SSR機能追加ライブラリ有)

◼︎Prefetching (プリフェッチ)

バックグラウンドでリンク先のページをあらかじめ読み込む技術です。

ユーザーがリンクをクリックしたときにはページがすでにロードされているため、読み込み時間なしで即座に遷移ができます。

Prefetching採用例

… Next.jsの<Link>タグ、Gatsby.js：デフォルト、Nuxt.js：「nuxt-link」使用

 

4. 最後に

いかがでしたでしょうか。

 

文字を読む時代から動画の時代へ。YouTube動画からShort動画の時代へ。…

と、より短いものがウケる傾向が強まっているように思います。

 

昨今はスマホ内に興味を引くものがたくさんあるため、昔と比べて読み込みを待ってくれない、すなわち “地球人総せっかち時代” に突入していると言っても過言ではないかもしれません。

そんな今だからこそ、パフォーマンスの見直しは意味があるのではないでしょうか。

また気になることを記事にしていきますので、よろしくお願いいたします。

最後までお読みいただきありがとうございました！

先日、情報通信月間参加行事として、弊社開催で「『未来を創る』AIツール活用セミナー」を行いました！

たくさんのご参加ありがとうございました。

生成AI、およびそれに関連するツールを受講者の皆さんと一緒に使用しながら、これからの未来について考えることができました。大変嬉しく思っています。

 

高知、松山、それぞれ4日間に渡り、開催いたしました。

 

AIはただの便利ツールではなく、人間の可能性をサポートしてくれる “コラボレーションツール” でもあります。

様々なワークショップを通じてみなさんにそれを体感していただきました。

 

また、AIがAIを評価するといったこれまでになかった概念について、今の時点からイメージを持ってもらうこともできました。

 

これからのAI技術

生成AIを普通に使うだけでなく、たっぷり時間をとり、これから一般層でも話題になっていくであろうRAG (検索拡張生成) も体験していただきました。

個別のドメインにも対応でき、個人データ・企業データを活用していく上での現実的なイメージを持っていただけました。

 

また、直近で出たOpenAIのモデル「GPT-4o」を用いた音声対話を使うことで、音声入力による手間のなさ、そして応答のスムーズさも体験していただきました。

マルチモーダルにより、AIと人との間の距離が格段に縮まったことを体験ベースで感じていただけたかと思います。

 

受講者の声

◼︎受講者レビュー

40代男性：「一人では新しいものに面倒でなかなか手が出せないので、新しいツールを実践的に教えてもらえて分かりやすかったですし、すごく楽しかったです。」

20代男性：「生成AIも使い方次第で色々使えることが分かったので、何に使おうかと今頭がグルグルしてます。」

40代女性：「今後も継続して、このようなセミナーを続けてほしい。」

 

◼︎受講者満足度

◼︎内容について

◼︎受講理由

◼︎受講して良かったと思った点

 

さいごに

各地開催で1ヶ月以上に及んだセミナーですが、開始時と終了時を比較しても生成AI周りはかなり技術が進んでいます。

進化が速いというのは、逆に言えばチャンスの回数が多いという風にも捉えられるかと思います。

皆さんがAIテクノロジーに積極的に触れていき、市民の側から世の中を変えていく ( = シビックテック) ことができればなという願いのもと、スタッフ一同尽力いたしました。

 

またなんらかの形でセミナーを開催したいと思いますので、その時は是非ともよろしくお願いいたします。

私たちと一緒に未来を創っていきましょう！

まず、RAGの前提知識といたしまして、ユーザーが登録するテキストデータを、どのようにして処理されレスポンスまで持っていくのかを軽くまとめさせていただきます。

(出典：NVIDIA DEVEROPER)

 

ドキュメントの自動処理 (Document pre-processing)

ドキュメントが読み込まれた後、内容を加工する必要があります。
その一つの方法がテキストのスプリットで、長いテキストを小さな部分に分けます。

これは、e5-large-v2というモデルが使える最大の長さが512トークンだからです。この分割作業は簡単そうに見えるかもしれませんが、実際には慎重に行う必要があります。

 

埋め込みの生成 (Generating embeddings)

データを扱いやすい形にするため、埋め込みを生成します。
埋め込みとは、テキストを数値の形で表現することで、これを高次元ベクトルに変換します。

 

埋め込みをベクトルデータベースに保存 (Storing embeddings in vector databases)

加工したデータと生成した埋め込みは、ベクトルデータベースと呼ばれる特別なデータベースに保存されます。これにより、データの検索や取得が速く行えます。

高速化されたデータベースに保存することで、リアルタイムで素早く情報を引き出すことができます。

 

LLMs

LLM（大規模言語モデル）は、RAGシステムの中心的な要素です。これらのモデルは大量のデータでトレーニングされており、人間のようにテキストを理解して生成することができます。

RAGのシステムでは、LLMがユーザーの質問に対して、ベクトルデータベースから取り出した情報を元にして、適切な回答を生成します。

 

クエリ (Querying)

ユーザーが質問をすると、RAGシステムはデータとベクトルを使って関連する情報を検索します。システムは、質問のベクトルとベクトルデータベース内のベクトルを比べて、関連する情報を見つけます。そして、LLMがその情報を使って、適切な回答を作り出します。

 

 

今回はそんなRAGに関して、「前処理」がいかに重要か語っていきたいと思います。

知っているかいないかでは大違い。ぜひお読みください。

 

◼︎RAGの前処理

トークン数に応じてテキストを分割する際、ランダムに分けるのではなく、文章の区切り、句点や段落が影響します。(以下参照)

Retrieval Augmented Generation (RAG) Done Right: Chunking

テキストが整頓されていないと、”この行がどこにかかっているのか” という構造が見えなくなってしまい、ハルシネーションを引き起こします。

情報の構造が違う形で読み取られてしまうと、RAGの意味がありませんね。

 

これを整える作業が「前処理」です。

具体的には、以下のように構造化し、マークダウン形式に近い形で整理してやります。

 

◼︎前処理を行なっていく

以前弊社の記事で紹介したGoogleサービス『NotebookLM』で検証を行いました。

https://notebooklm.google/

 

題材は、松山市のマイナンバー申請手続きに関するページです。

https://www.city.matsuyama.ehime.jp/kurashi/tetsuzuki/mynumberseido/mynumber.html

(↓前処理なしデータ)

これを以下のプロンプトで GPT-4o に渡し、前処理を行いました。

---

以下のテキストを、RAGに使うテキストファイル用に整頓してください。

マークダウン形式が望ましいです。

=====

[全文]

---

 

(前処理ありデータ)

 

◼︎前処理の前後で比較

同じ質問を投げ、前処理なしとありで比較していきましょう。

・質問：「マイナンバーカード申請には何が必要ですか？」

ちなみに正解がこちらです。

それでは比較を見ていきましょう。

 

---

[前処理なしの回答]

マイナンバーカードの申請に必要なものは以下のとおりです。

* **申請書**: 申請書は窓口でも入手できます。代理人が申請する場合は、本人が必要事項をすべて記載し、顔写真を貼付する必要があります。
* **顔写真**: 縦4.5センチ×横3.5センチで、6か月以内に撮影したものを用意してください。 松山市役所本館1階の市民課にあるマイナンバーカード専用窓口では、申請用顔写真の無料撮影サービスを実施しています。
* **本人確認書類**: 15歳未満または成年被後見人の場合は、法定代理人の同行も必要です。

これらのものを持参して、市役所の窓口または郵便局で申請手続きを行うことができます。 また、スマートフォンやパソコンを使って、自宅からでも申請手続きを行うことができます。

 

---

[前処理ありの場合]

マイナンバーカードの申請には、以下のものが必要です。

* **申請書**: 代理人が申請する場合は、本人が必要事項をすべて記載し、顔写真を貼付する必要があります。様式は窓口にもあります。
* **顔写真**: 縦4.5センチ×横3.5センチの6か月以内に撮影したものを用意してください。松山市民課では、申請用顔写真の無料撮影サービスを実施しています。

申請時に必要なものは、申請方法によって異なる場合がありますので、詳しくはソースをご確認ください。

---

 

一見問題ないように見えるのが厄介ですが、[前処理なし] の方は誤った情報が返ってきているのがわかると思います。

↑ ここの部分を変に読み取り、「本人確認書類」を勝手に追加してしまっているようです。

◼︎現状の課題

ファインチューニングと違い、RAGは登録するファイルの質が問われてきます。

手軽な反面、前処理の質によって回答が変わってくるのは難点です。

上記で紹介したように、前処理を以下のようなプロンプトでAIに任せるのも手です。

---

以下のテキストを、RAGに使うテキストファイル用に整頓してください。

マークダウン形式が望ましいです。

=====

[全文]

---

 

しかし理想を言えば、それすら自動で行ってくれるのが楽ではないでしょうか。

今後半年、もしくは1〜2年の間で、そこの手間が無くなるような改革が起こる予感がしています。

今後も注目し、ハックしていこうと思います。

◼︎まとめ

いかがでしたでしょうか。

RAGは「パーソナルAI」を体現する技術です。間違いなくこれからもっと注目され、一般層にも馴染みの深いものとなっていくでしょう。

また気になるトレンドや技術を記事にしていきますので、お読みいただけますと幸いです。

お読みいただきありがとうございました！

GoogleがAppleに対し、お金を払っているのを皆さんはご存知でしょうか。

それも年間で3兆円弱。かなりの額ですね。

iPhone (Safari) のデフォルト検索エンジンにしてもらうために支払われているそうです。

 

今回はこちらの記事を参考に、両社の関係やアプローチ、それに伴う動きについて触れていきます。
https://www.gizmodo.jp/2023/10/google-pays-apple-18-billion-for-search-engine-default.html

 

なぜ大金が動くのか

年間180億ドルから200億ドル（約2兆6000億円〜2兆9000億円）。

資産運用会社調べでは、この額はAppleの年間営業利益のおおよそ15％に相当するとのことです。

Appleの収益の15%はGoogleからの支払いということになります。

Googleに対する反トラスト訴訟 (独占禁止法的な観点での訴訟) の中で、主任訴訟担当官が、Googleの支払い額を100億ドル以上と推定しているそうですが、新しい推定では180億ドルから200億ドル（約2兆6000億円〜2兆9000億円）の規模になるだろうと言われています。

Google社内でも2007年に

「私たちが市場を独占するブラウザであることは、ユーザーエクスペリエンスとしてよいものではないし、印象もよいとは言えない。」

という声が上がったとの話もあり、また裁判所がGoogleに対し (Appleとの) 契約解除を命令する可能性についても浮上しているとのことです。

 

デバイスを持つAppleへのアプローチ

Googleは本音ベースでは、iPhoneユーザーにはSafariに依存してほしくないものと思われます。

実際に以下の記事は、iPhoneユーザーのSafariブラウザー以外からの検索量を増やすことを目標とした記事です。

https://www.theinformation.com/articles/google-struggles-to-lessen-reliance-on-apple-safari

Googleのブラウザである「Google Chrome」の普及に力を入れ、デバイスプラットフォームを持つAppleに対してアプリケーションレイヤーからアプローチを行なっています。

 

ところで、Appleといえば今年「Apple Intelligence」を発表しましたね。

その発表の目玉として、iOS18からAppleデバイスに、OpenAIのLLMモデル「ChatGPT」が組み込まれるという情報が出てきました。

OpenAIはセキュリティ面を強化することで、アプリケーションレイヤーよりもっと深く、OS深部までアプローチを試みる可能性がありますね。

まとめ

いかがでしたでしょうか。

弊社HAVASもAIエージェント開発に力を入れていますが、今回のような話題も参考にしながら柔軟に渡り歩いていきたいと思っております。

大規模言語モデル (LLM) をはじめとした各種ツール間のエージェントも模索しつつ、データベース (ベクトルDBなど) をはじめとした深いレイヤーの洞察および開発も視野に入れつつ、引き続き尽力していきたいところです。

今回もお読みいただき、ありがとうございました。

先日、アイテムえひめにて「おしごとフェスタ2024」が開催されました。

 

弊社の八木さんがVR体験のブースを構え、2日間で合計74名の方に体験をしていただきました。

八木さんはプログラミング歴40年、Slerとして25年の経験を持つ方です。

0から1を生み出すことが得意であり、AIだけでなく、VR、ブロックチェーン、IoT、量子コンピュータにも挑戦している魔法使い。

DB周りからWebアプリまでオールラウンドにこなす、頼もしい存在です。

 

今回の経験を踏まえ、他従業員ともども今後の技術修練に邁進していきたいと思います。
この度は、本当にありがとうございました。

進化が非常に速いAI業界ですが、最近はRAG (検索拡張生成) を行えるサービスがじわじわと活発になっている印象です。

 

今日はそんなRAGについて、ファインチューニングとの違いを述べる形で解説し、実際にRAGが手軽に行えるサービスもご紹介していきます。
しばしお付き合いください。

(参照記事)
https://leapwell.co.jp/tech_column/blog-finetuning-vs-rag

◼︎ファインチューニングについて

「ファインチューニング」の方が耳馴染みのある方は多いのではないでしょうか。

ファインチューニングは、AIモデルに新しい知識や特定のタスクを学習させるプロセスです。モデルに対してトレーニングデータを用意し、そのデータをAIに学習させます。モデルは既存の知識を基に新しい情報を習得していきます。

 

小出しでフライングですが、RAGではモデル自体の知能は変わらないのに対し、ファインチューニングでは、モデルがトレーニングを通じて新しい知識を自身の経験として取り入れるため、モデルの知能も特定のタスクに向けて変化します。

ファインチューニングで一番大変なのは、学習データの準備や学習時間と費用が必要なことです。
OpenAIの公式サイトによれば、<役割 / 質問 / 回答> の形式で少なくとも50個の学習データセットを準備することが推奨されています。
このデータセットを作成するだけでなく、学習結果を見ながら精度を上げるための調整や手間も必要です。

◼︎RAGについて

RAGは、事前に用意されたアップロードファイルを参照しながら回答を生成する技術です。

質問内容がマニュアルに記載されている情報に基づいていれば、RAGは適切な回答を提供できます。

 

質問に対して関連する情報をマニュアルから自動的に検索し、その情報をもとに回答を生成するイメージです。

もっと具体的に言えば、プロンプトを与えられた際に、関連性の高い部分をマニュアル内から検索し、その結果をプロンプトに追加してから回答を生成するという手法です。

RAGには利点がありますが、もちろん欠点も存在します。
ファイルの内容を理解しているわけではなく、単にマニュアルを参照して関連情報を探し出しているだけであるため、回答の質はマニュアルの内容と検索アルゴリズムの精度にどうしても依存してしまいます。

しかしながら、(状況とニーズに応じた使い分けは必要ですが、) 比較的RAGの方がハードルが低いことは明らかですね。

 

◼︎RAGを行えるサービス

最後にRAGが行えるサービスを一つ紹介して終わりにします。

先日世に出てきた「NotebookLM」というサービスをご存知でしょうか。
https://notebooklm.google/

Googleが出しているサービスで、手軽にRAGを実行できます。

・左側「ソース」にプラス (+) マークからファイルを追加する
・チャットで質問を投げる

やることは最低限これだけです。

返ってきた回答には番号が振られていて、クリックするとどこを参照したのかハイライトで確認ができます。

詳細やもっと具体的な機能・使い方は以下のサイトに良くまとまっていますので、ぜひご覧ください。

https://weel.co.jp/media/innovator/notebooklm/

今回もお読みいただきありがとうございました！

皆さんは「ベクトルデータベース」(別名：ベクターDB、ドキュメントDB) というものをご存知でしょうか。

データベースと聞くとMySQLやPostgreSQLをはじめとするRDB (リレーショナル・データベース) 、すなわち表形式で管理する従来のデータベースを思い浮かべる方が多いかと思いますが、それとは別の新しい形式のデータベースです。
ここ1〜2年、”AIに適したデータベース”との呼び声でじわじわ話題になっています。

今回はそんなベクトルDBを比較しながら深掘っていきます。

◼︎そもそもベクトルデータベースとは？

「従来のRDBが表形式だとしたら、ベクトルDBはどういった形式なのか？」
そういった疑問が必ず出てくると思いますので、まずはそれを紐解きます。

以下のサイトが参考になりますので、軽く抜粋いたします。
(参照)

https://qiita.com/ksonoda/items/ba6d7b913fc744db3d79

 

単語をベクトルとして考え、「意味空間」の中にプロットするイメージだそうです。
座標の表し方は一般的なベクトル同様、
2次元であれば (a, b)、3次元であれば(a, b, c)
となりますが、ベクトルDBは次元が100まで及ぶこともザラにあります。

どうしても人間は4次元以降の空間を把握できずイメージはつきませんので、変数が100個あるくらいに考えておくのが良いかと思います。

意味の近い単語同士が近くにあり、検索を被るようなイメージですので、LLM (大規模言語モデル) との相性が非常に良いと言われていますね。
これが、最近になって急激に注目され始めた理由とも言えます。

近似度は、「大きさ」と「向き」の類似度によって割り出されるようです。
※「大きさ」の類似度…各データのドット間の距離差
※「向き」の類似度…原点からの角度差

◼︎ベクトルDBの比較を考える

そんなベクトルDBにも様々プラットフォームがあり、各々に特徴があります。どんなベクトルDBがあるのか分からない、また選び方も分からないという方がいると思いますので、そんな方のお役に立てますと幸いです。

(今回参照した記事)

https://www.aireview-nlp.com/vectordb/

上記の表作成者である、Vectorview社の共同創設者エミール・フレーベリ氏の解説を和訳し、以下に共有いたしますので、ご参考にしていただけますと幸いです。

ちなみにこのVectorview社、AIの評価 (安全性、パフォーマンス) や、ビジネスへのAI導入をサポートしている会社らしいのですが、HPのドメインが「.ai」となっていてこだわりが凄いです。
https://www.vectorview.ai/

余談はさておき..。

 

・オープンソースおよびクラウドホスティング：

オープンソースソリューションを選好するなら、Weviate、Milvus、およびChromaが有力候補です。
Pineconeはオープンソースではありませんが、開発者の使いやすさと強力な完全ホスティングソリューションで際立っています。

 

・パフォーマンス：

秒あたりのクエリ数（QPS）に関しては、Milvusがトップで、WeviateとQdrantがそれに続きます。
しかし、レイテンシー（遅延）に関しては、PineconeとMilvusがどちらも2ms未満の優れた結果を提供しています。Pineconeに複数のポッドを追加すれば、さらに高いQPSを達成できます。

 

・コミュニティの強さ：

Milvusは最大のコミュニティを誇り、次いでWeviateとElasticsearchが続きます。
強いコミュニティは、より良いサポート、改善、およびバグ修正に繋がることが多いです。

 

・スケーラビリティ、先進機能、およびセキュリティ：

多くの企業アプリケーションにとって重要な役割ベースのアクセス制御（RBAC）は、Pinecone、Milvus、およびElasticsearchに搭載されています。
スケーリング面では、動的セグメント配置を提供するMilvusとChromaが進化し続けるデータセットに適しています。
幅広いインデックスタイプを必要とする場合、Milvusの11種類のインデックスタイプのサポートは他に類を見ません。ハイブリッド検索は全体的によくサポートされていますが、Elasticsearchはディスクインデックスサポートにおいて劣ります。

 

・価格：

スタートアップや予算に制約のあるプロジェクトには、Qdrantの50,000ベクトルで推定9ドルという価格は魅力的です。
一方、高いパフォーマンスを必要とする大規模プロジェクトには、PineconeとMilvusが競争力のある価格帯を提供しています。

 

まとめ

いかがでしたでしょうか。

ベクトルDBのイメージが沸かないという方や、各種ベクトルDBの特徴・選び方が知りたいという方のお役に立てたなら幸いです。
比較に関しては、理想のDBがあるわけでもなく、ニーズや状況に応じて上記を参考にする形となろうかと思います。

また、最近話題に上がり始めている、SQL構文を扱えるベクターDBのハイブリッドDBにも注目しています。

上記はRDBに慣れている方でも入りやすいかと思いますので、機会があれば詳しく調べ、記事にしたいと思っております。

ここ1〜2年、急速なスピードで進化と変化を繰り返す生成AI、これが今後どうなっていくのか非常にワクワクいたします。

お読みいただきありがとうございました。

 

昨日6月10日、Appleから「Apple Intelligence」なるものの発表がありました。

昨今「GPT-4o」で音声対話機能が大幅に向上したこともあり、AIはほぼ間違いなくマルチモーダルに向かっていくことを考えると、カメラ機能と音声マイクを持つスマホ環境が生成AIの普及には欠かせません。
https://news.yahoo.co.jp/articles/b3e61d9d8e5e8aa47fdc94b11e6097fe9e7010f3

今回の「Apple Intelligence」の発表はまさにそれに順当な動きではないでしょうか。

Androidを握っているGoogleが持つGeminiにはこれまで一定の優位性があったように思いますが、OpenAIとAppleが組んだことでそこもかなり変わったように思います。

今回の件は発表元のAppleにとってのメリットよりも、マルチモーダルのセンサーであるカメラと音声デバイスプラットフォームとを手に入れた、OpenAIの方がメリットが大きいと考えることもできるのではないでしょうか。

 

今まで切り離されたツールとして、”対象物” のように我々が使用していた生成AIですが、今後はデバイスと融合し一体化され、我々が必要以上に意識しなくても自然と使われるようになっていくようです。

“「便利ツール」の時代から「パートナー」へ”

私たちが今スマホを手放せなくなっているように、生成AIも必需品、いや必需”器官”として生活に溶け込んでくるのかもしれません。

 

今回は以下の公式の記事から、気になった部分をピックアップしていきます。

https://www.apple.com/jp/newsroom/2024/06/introducing-apple-intelligence-for-iphone-ipad-and-mac/

◼︎言語を理解し、言葉を作成する新しい機能

メールやメモなど、文章作成を行うあらゆる場面で、文章の書き直し、校正、要約を行ってくれるとのことです。

また、記述形式の変更ができ、すでにあるテキストを選択するとそれを読みやすい段落、箇条書き、表、リストなどの形にまとめることができるようです。

 

◼︎「優先通知」という新しいオプション

AIが、重要な通知か否かを判断し、重要なものだけは表示させるという全く新しい集中モードが実装されるようです。

まさに「痒いところに手が届く」機能だと思います。

 

◼︎画像作成機能「Image Playground」

画像作成の機能が、メッセージなどのアプリに直接組み込まれるようです。
従来のようにプロンプトによる生成が可能で、また、写真ライブラリから生成画像に含める人物を指定できるとのことです。

自分が生成する画像に友人を登場させることができるのは、今までになかった機能ですね。

 

◼︎写真の新しい機能

写真やビデオを検索するとき、
「マヤが絞り染めTシャツを着てスケートボードをしている」
「顔にステッカーが付いているケイティ」といった自然な言葉によって検索が可能になるようです。

また、新しいクリーンアップツールによって、写真の背景にある不要な対象物を特定して削除できます。

 

◼︎「Siri」の能力が向上

画面認識により、Siriがユーザーの操作履歴やコンテンツを理解するようです。
時間が経つにつれて、具体的なアクションを実行できるようになります。

例)
友人が新しい住所を送ってきた時に、「この住所を彼の連絡先カードに追加して」と指示する
「友人が勧めてくれた曲を再生して」と言えば、メッセージやメールからそのやりとりを探して再生してくれる

 

◼︎Appleのプラットフォーム全体にChatGPTを統合

Appleデバイス (まずは iOS 18、iPadOS 18、macOS Sequoia内で) から直接ChatGPTにアクセスできるようになります。
また、Siriも必要に応じてChatGPTにアクセスし情報を返してくれるようです。
今までアプリ等で行っていた、GPTへのアクセスが、デバイスやOSで直接かつナチュラルに使用できるようになりますね。

 

まとめ

いかがでしたでしょうか。

今後もトレンドを追い、気になることは記事にしていきますので何卒よろしくお願いいたします。
お読みいただきありがとうございました！