Anri Nakamura

Kakemu Fujii

Kento Kaseda

Reo Hakuta

Erika Sakurai

erikasakurai

Takaharu Nakamura

Daichi Hachisuka

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

3ヶ月の開発インターンで取り組んだタスクや、そこから得た学びについて紹介します。

プレイドインターン体験記：管理画面から配信基盤までを横断した機能開発

<p>こんにちは、 プレイドでソフトウェア開発者をしているtakurintonです。</p>
<p>プレイドは、2025年10月25日(土)に開催された<a href="https://vuefes.jp/2025/">Vue Fes Japan 2025</a>にゴールドスポンサー、学生支援スポンサーとして協賛しました。</p>
<p>当日はブースの出展に加え、プレイドのユニークな技術とインターンの紹介をさせていただきました。</p>
<h2>ブースの紹介</h2>
<p>プレイドは大規模データを扱う会社である一方で、配信を誰でも簡単に行うことができるUIにも力を入れています。</p>
<p>ブースではフロントエンドの以下のトピックに関するアンケートを実施しました。</p>
<ul>
<li>型、どうしてる？</li>
<li>CSSは何派？</li>
<li>1番重要視するのは？</li>
<li>UI状態管理は？</li>
<li>ビルド&amp;Dev環境を教えて！</li>
<li>推しパッケージマネージャーは？</li>
</ul>
<p>プロダクトの歴史的背景や、場合によっては意思決定者の好みが出る話題で、さまざまなバックグラウンドの方の話や事情を聞くことができ、大変学びになりました。</p>
<p>また、併せて今回のVue Fes Japan 2025に向けて作成した冊子や、プレイドのリアルタイム解析基盤や内製OLAP DBについて技術評論社様と作成した冊子などを配布しました。</p>
<p><img src="https://ik.imagekit.io/plaid/e93f049b-91b9-4a6b-9360-97552fc1f36c/IMG_2541.jpg" alt="Vue Fes Japan 2025の株式会社プレイドのブースの様子。パンフレットやモニター、アンケートボードが並べられている。"></p>
<h2>セッションの感想</h2>
<p>同じ学生支援スポンサーで登壇されていたお二方のセッションの感想を書いていきたいと思います。</p>
<p>お二方とも大変ユニークで面白く、それぞれの抱えている課題について端的に発表されていることが印象的でした。</p>
<h3><a href="https://vuefes.jp/2025/sponsors/lycorp"><strong>LINE公式アカウントの技術スタックと開発の裏側</strong></a></h3>
<p>LINEヤフー株式会社の佐野友亮さんの発表です。</p>
<p>LINE公式アカウントのプラットフォームを題材に、デザインシステムの取り組みについてお話しされていました。<br>
デザインシステムの中核部分はWeb Componentsで実装されており、それをReactやVue.jsなど複数のライブラリへ適用できる仕組みになっているとのことでした。具体的には、CEMというツールを用いて中間表現を生成し、ReactやVue.js向けのコンポーネントはその生成物を配布する形を取ることで、メンテナンス対象をWeb Components部分に集約している構成が紹介されていました。</p>
<p>Web Componentsを本番環境で活用している事例は個人的に初めてで、以前から関心を持っていたテーマだったこともあり、とても学びの多い内容でした。</p>
<h3><a href="https://vuefes.jp/2025/sponsors/studio"><strong>Vue.jsを8年間使ってきた会社が今考えていること</strong></a></h3>
<p>Studio株式会社の齊藤広野さんの発表です。</p>
<p>Vue.jsを1系の頃から8年間にわたって活用されており、その間にコード量は7年間で13倍に増加していたそうです。発表では、大規模アプリケーションにおけるStore設計の重要性を、単一責任の原則や依存性逆転の原則を題材に、具体的なサンプルコードを交えて丁寧に解説されていました。</p>
<p>また、プロジェクトのデータ構造がボトルネックとなり、パフォーマンスが大きく低下していたアプリケーションをマイグレーションする難しさや、その過程で発生した不具合から得た知見をもとに改善へとつなげていく姿勢が印象的でした。実践的かつ学びの多い内容だったと思います。</p>
<h2>スポンサーセッション</h2>
<p><a href="https://vuefes.jp/2025/sponsors/plaid">プレイドのユニークな技術とインターンのリアル</a></p>
<p>弊社のスポンサーセッションでは、プレイドが提供するKARTEの紹介をはじめ、開発文化やユニークな技術についての紹介を行いました。また、途中では<a href="https://blocks.karte.io/">KARTE Blocks</a>のデモを挟みながら、実際の画面や配信についても触れました。</p>
<p>フロントエンドという領域から離れてしまいましたが、リアルタイム解析基盤や内製しているOLAP DBについての紹介も行いました。</p>
<p>セッション後にブースに立ち寄ってくださった方々からは技術面の面白さを感想としてお伝えいただいたり、時には議論に発展したりと、大変学びになる時間になりました。</p>
<p>よろしければ登壇資料もご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="プレイドのユニークな技術とインターンのリアル" src="https://speakerdeck.com/player/0ee327d57ec64e71b058a9a777c71d51" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h2>おわりに</h2>
<p>Vue Fes Japan 2025では主にフロントエンドの分野に深い知見をお持ちの方が多く参加されており、自分自身その領域への知見や経験が足りないと感じていたのでさまざまなお話を聞くことができ大変有意義な時間になりました。</p>
<p>最後になりますが、素晴らしいカンファレンスを主催・運営してくださった皆様、本当にありがとうございました！また、ブースの出展に携わった皆様、登壇者・参加者の皆様も本当にお疲れ様でした！</p>
<p>来年のVue Fes Japanも楽しみです。</p>


プレイドはVue Fes Japan 2025にゴールドスポンサー、学生支援スポンサーとして参加しました。セッションの感想やブースの運営についてレポートとして紹介します。

Vue Fes Japan 2025レポート | 現地で感じた技術の熱とつながり

<p>こんにちは、藤井駆陸です。普段は化石について研究している大学院生です。9月の間、プレイドのJourneyチームにてインターンに参加しておりました。</p>
<p>振り返れば一瞬に感じられた1ヶ月でした。頭を抱えながら巨大なアーキテクチャの概要を掴み、タイムゾーンとSQLに苦戦しながら多くの実装をし、検証用環境を追い込んで問題点を洗い出す。そんな目まぐるしい日々でした。</p>
<p>この記事では、実際に関わったタスクや、インターンの率直な感想についてお伝えできればと思います。</p>
<h2>導入</h2>
<h3>インターン参加の経緯</h3>
<p>最初のきっかけは、プレイドで働く友人から、仕事がとても充実していると聞いたことでした。<br>
面談や面接でお話を伺う中で、カルチャーなどに加えて、技術的に難易度の高い大規模データを扱う挑戦に魅力を感じました。<br>
「自分もこの環境に飛び込み、挑戦したい」と強く感じ、このインターンシップに参加しました。</p>
<h3>Journeyとは？</h3>
<p>プレイドが提供するプロダクト「KARTE」において、ユーザーの辿る行動に応じて、異なる施策を実行することができる機能です。例えば、ECサイトで「カートに商品を入れたまま迷っているユーザーに、2時間後にクーポンの通知を送る」といった、ユーザーの状況に応じたシナリオを自動で実行してくれます。</p>
<p>参考：<a href="https://karte.io/product/journey/">KARTE Journey</a></p>
<p>現在、Journeyチームでは配信基盤周りの改善を行なっています。その中核としてユーザーのイベントが発火した瞬間に処理を行う「イベント処理基盤」と、指定時間の経過や条件の評価などをバッチ処理で行う「定期実行基盤」を開発しています。<br>
今回は「定期実行基盤」にまつわるタスクを行いました。</p>
<h2>業務内容紹介</h2>
<h3>時間経過の判定の処理のリアーキテクチャ</h3>
<p>Journeyにおいてシナリオは、ユーザーの行動や通知の配信などといった1つ1つのステップに分けられます。その中には、「指定時間までユーザーを待つ」といったものもあります。そこでは、「2時間後」「毎週金曜の18:00」「月末の12:00」など、様々な条件でユーザーが留まる時間を指定することができます。</p>
<p><img src="https://ik.imagekit.io/plaid/7bd172a8-fccb-4f88-b8c7-932f98ea5b8c/blog_image_1.png" alt="blog_image_1.png"></p>
<p>定期実行基盤の主要な部分として、各ステップの遷移対象となるユーザーを抽出するコンポーネントと、遷移対象のユーザーを実際にデータベースに書き込んで次のステップへ移すコンポーネントがあります。</p>
<p>従来の実装では、データ更新を担うコンポーネント（下図右側）が、ユーザーを待つ処理がある時には「ユーザーの待ち時間の終了時刻を計算する」という処理も行なっていました。本来書き込みに専念すべき場所に、時刻計算のビジネスロジックが混在して責務が曖昧になり、全体の見通しの悪さが課題となっていました。</p>
<p><img src="https://ik.imagekit.io/plaid/d14465ef-2fd8-43d2-9d4b-02e3d39884e8/blog_image_2.png" alt="blog_image_2.png"></p>
<p>そこで、遷移を実行するコンポーネントで書き込み処理に専念できるよう、遷移対象を抽出する段階で動的にSQLを生成するように実装を変更しました。*1<br>
具体的には、TypeScript側で「現時点でいつの時刻まで流入してきた人が遷移対象となるべきか」を計算し、それを用いてクエリを書くといった実装でした。</p>
<p>*1: BigQueryのUDF(User defined function)も検討しましたが、行数を少なく実装できる一方で可読性やメンテナンス性が低かったため見送りました。</p>
<p><img src="https://ik.imagekit.io/plaid/72d50f67-2cbf-4a7a-9682-c6fb7d3d5a83/blog_image_3.png" alt="blog_image_3.png"></p>
<p>大変だったことは、網羅すべきパターンが多く、単純な計算なのにも関わらずコード量が膨大になったことです。初めはパターンごとにクエリを実装していましたが、SQLの構造が2つのパターンに集約できるのを見抜いて、計算部分を切り出しました。まだまだSQLの動的生成の可読性は課題ではあるものの、コードの見通しはある程度良い状態で実装ができました。</p>
<p>実装の細部にまで目を配ってレビューしていただき、非常に勉強になりました。例えば、待ち時間のパターンに対して Discriminated Union の導入を提案いただいたことで、より型安全に整理できました。このように、今まで知らなかった技術を活かして実践的なコード改善に繋げるという貴重な体験は、自身の成長に大きくつながりました。</p>
<h3>定期実行基盤の負荷検証</h3>
<p>次に、クラウドインフラのリソースを増やすことによって定期実行基盤が本番トラフィックを処理可能か、そのスケーラビリティを検証するための負荷テストを行いました。</p>
<p>目標実行時間を2分半以内と設定し、大量の検証用データを投入してテストを開始したのですが、現実は甘くありませんでした。実行時間は常に目標を大幅に上回り、ボトルネック探しの調査が始まったのです。</p>
<p>以下の流れで負荷検証を行いました。</p>
<ol>
<li>データ大量投入スクリプトの準備</li>
<li>検証</li>
<li>デプロイ設定の変更(複数回)</li>
<li>Datadogメトリクスの導入</li>
</ol>
<p><strong>仮説1：ユーザー抽出時のリソース不足</strong></p>
<p>まず疑ったのは、コンピューティングリソースの不足です。</p>
<p>実際に、テストの初期段階ではcpu使用率が頭打ちしていて、メモリにも余裕がない状況でした。GKEのpod数を10程度まで増やしてリソースを潤沢に確保しました。しかし、CPU使用率は安定したものの、実行時間は依然として5分を超過したままでした。</p>
<p><img src="https://ik.imagekit.io/plaid/fd0a8e70-2268-408f-b9f2-a133f8398704/blog_image_4.png" alt="blog_image_4.png"></p>
<p><strong>仮説2：データベース処理の遅延</strong></p>
<p>次に目を向けたのは、データベース、特にBigQuery(BQ)の処理です。Temporalのワークフローの実行記録(上の画像)から、BQでの一時テーブル作成やSpannerへのエクスポートの処理に時間がかかっている可能性が浮かび上がりました。</p>
<p>これを検証するため、Datadogで各BQクエリの実行時間を計測可能にしました。その結果、クエリの実行時間は最長で10秒程度であることがわかりました。5分以上の実行時間を説明するには不十分でした。</p>
<p><img src="https://ik.imagekit.io/plaid/39f98e76-7cac-4acf-bb7a-1911ff967d40/blog_image_5.png" alt="blog_image_5.png"></p>
<p><strong>真相：直列実行の罠</strong></p>
<p>八方塞がりかと思われた中で、GKEのログを見てみたところ、驚くべき事実が判明しました。<br>
調査の結果、検証環境では本来並列で実行されるべき多数のタスクが、なぜか直列に一つずつ処理されていたのです。すなわち、BQやSpannerのIO待ちが積み重なっていたということです。<br>
今回のボトルネックの正体は、「デプロイされた環境における並列処理の不具合」だったのです。<br>
最終的に問題を完全に修正するところまで至りませんでしたが、この調査プロセスは非常に大きな学びとなりました。<br>
「仮説を立て、データを用いてそれを検証し、次の打ち手を考える」というサイクルを高速で回すことの重要性を肌で感じました。巨大なシステムにおける問題解決のリアルな一端に触れられた、非常に価値のある経験でした。</p>
<h2>インターン生活について</h2>
<h3>プレイドでの働く環境</h3>
<p>全体的にオープンな雰囲気で、誰にでも気軽に質問や相談ができました。特に印象的だったのは、タスクに関する何気ない相談が、次第にプロダクトの設計といった、より深い議論に発展していく光景でした。1人の思考がチームとしての思考に拡張されてゆくような、新鮮な体験でした。<br>
また、ランチの時間には他のチームの方とも交流することができ、毎日楽しく過ごすことができました。インターン生同士や新卒の方などとの繋がりもできてよかったです。</p>
<h3>インターンを通しての学び</h3>
<p>この1ヶ月で、エンジニアとして多方面にわたり大きく成長できたと感じています。<br>
実装における細かい技術的な側面から、プロダクトの提供する価値といったビジネス的な側面まで、幅広い視点でインプットできました。<br>
その中でも特に、データを大量に投入してパフォーマンスを観察するといったことは、自分一人ではできない新たな経験でした。大規模なデータを処理するアプリケーションのインフラの一端を覗くことができ、非常に勉強になりました。</p>
<h2>最後に</h2>
<p>この1ヶ月は、手厚いサポートを受けながらも手応えのあるタスクに没頭することができ、非常に充実した時間でした。改めて、Journeyチームの皆様には心から感謝しています。<br>
このインターンは、刺さる人には深く刺さるものだと感じています。「手応えのあることに挑戦したい」「新しい技術に触れてみたい」といった方には最高の環境です。<br>
そのワクワクするような経験を、ぜひ次はご自身で体験してみてください。</p>


こんにちは、藤井駆陸です。普段は化石について研究している大学院生です。9月の間、プレイドのJourneyチームにてインターンに参加しておりました。  振り返れば一瞬に感じられた1ヶ月でした。頭を抱えながら巨大なアーキテクチャの概要を掴み、タイムゾーンとSQLに苦戦しながら多くの実装をし、検証用環境を追い込んで問題点を洗い出す。そんな目まぐるしい日々でした。  この記事では、実際に関わったタスクや、インターンの率直な感想についてお伝えできればと思います。

プレイドインターン体験記：大規模システムのリアーキテクチャと負荷検証

<p>KARTE for Appチームのエンジニアの悴田です。</p>
<p>プレイドは、2025年9月19日〜21日に開催された <a href="https://iosdc.jp/2025/">iOSDC Japan 2025</a> にゴールドスポンサーとして協賛し、ブース出展も行いました。<br>
本記事では、当日のブースの様子と、聴講した中で特に印象的だった4つのセッションについてご紹介します。</p>
<h2>ブースのご紹介</h2>
<p>プレイドでは、モバイルアプリ向けのSDKを開発・提供しています。</p>
<p>現在は、モバイルアプリのエンゲージメント向上を目的とする「<a href="https://karte.io/package/app/">KARTE for App</a>」と、Native UIの開発生産性向上を目的とした新規プロダクト (本記事公開時点ではクローズドベータ)、の2つを提供しています。<br>
今回のブース企画・運営は、これら2チームの開発メンバーを中心に行いました。</p>
<p>ブースでは、「<strong>アプリグロースの課題に関するパネルアンケート</strong>」と「<strong>マーケティングSDKの利用状況に関するWebアンケート</strong>」の2つを実施しました。</p>
<p><img src="https://ik.imagekit.io/plaid/b4be8f0a-852a-4130-8084-919d5678507c/IMG_0075.jpg" alt="IMG_0075.jpg"></p>
<p>アンケートにご協力いただいた方々には、弊社のノベルティグッズをプレゼントしました。<br>
ノベルティグッズとして「ラムネ」「歯磨きセット」「携帯式のコップ」「米 (2合)」を用意し、特に「米」は物珍しさもあって好評でした。</p>
<p>また、Webアンケートは弊社の「KARTE」を用いて作成し、アンケートの回答後にはくじを引けるようにしました。<br>
見事当たりを引いた方には、弊社のエンジニアが厳選した技術書の中から、お好きな一冊をプレゼントさせていただきました。</p>
<p><img src="https://ik.imagekit.io/plaid/740576ff-fc73-4bc2-ab3b-544df4b54c73/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-09-2915.02.17.png" alt="スクリーンショット2025-09-2915.02.17.png"><br>
当選者の方々 (ブログ掲載許諾取得済み)</p>
<h2>印象に残ったセッション</h2>
<p>テストやビルドといったMobile SDK開発にも関係するセッションや、個人的に興味のある低レイヤー寄りのセッションを聴講しました。</p>
<h3>1. 半自動E2Eで手っ取り早くリグレッションテストを効率化しよう</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="半自動E2Eで手っ取り早くリグレッションテストを効率化しよう" src="https://speakerdeck.com/player/b2991526951744758463d4663866c514" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>タイミー社での、E2Eテストの効率化に向けた現実的なアプローチが紹介されました。</p>
<p>当初、同社ではCI/CDとSaaSを活用した全自動のE2Eテストを目指していましたが、SaaSを使いこなす難しさや、SMS認証・QRコード読み取りといった実機特有のテスト項目が障壁となり、1年以上かけても安定運用には至らなかったそうです。</p>
<p>そこで、全自動化を諦め、以下のような「<strong>簡単にできる部分だけ自動化する</strong>」という半自動の方針に切り替えました。</p>
<ul>
<li>ローカルPCでアプリをビルドし、実機にインストールしてテストを実行する。</li>
<li>テスト自動化ツールとして、Railsで使い慣れている「Ruby」で記述できるAppiumを使用する。</li>
<li>自動化できない処理は、手動で操作する。スクリプト内にsleepメソッドを入れ、一時停止中に手動で操作する。手動操作のタイミングは、音を鳴らす仕組みで伝える。</li>
<li>うまく検出できないUI要素は、OCRを利用した画面タップで対応する。</li>
</ul>
<p>このアプローチにより、<strong>わずか1ヶ月で運用を軌道に乗せることに成功</strong>したそうです。</p>
<hr>
<p>私たちのチームにおいても、Mobile SDKのテスト自動化は重要な課題の一つです。<br>
本セッションで語られている、完璧を求めず、最小の労力で最大の成果を得ることを目指すアプローチを取り入れたいと思いました。</p>
<hr>
<h3>2. Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム" src="https://speakerdeck.com/player/89fc533243314e52a7bca2e17d6a4c23" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>XcodeならびにSwift Package Manager (SPM) において、Swiftコードがビルドされる流れと、その際に利用される各種ツール (`xcodebuild`, `swiftc`, `llbuild`など) の役割が紹介されています。</p>
<p>Xcodeでのビルドの場合、まずはXcodeが*.xcodeprojから「<strong>llbuildマニフェスト</strong>」を作成します。llbuildマニフェストとは、<strong>ビルドに必要なタスク一覧とそれらの依存関係を記述したファイル</strong>です。<br>
続いて、llbuildマニフェストは「llbuild」に渡され、実際のビルド処理をコンパイラ (swiftc/clang) やリンカ (ld) を用いて実行します。</p>
<p>一方、SPMでのビルドの場合には、SPMがPackage.swiftからllbuildマニフェストを生成し、llbuildに渡します。<br>
このような、<strong>llbuildマニフェストを生成するツールの違いが、XcodeとSPMの機能差の一因</strong>となっています。</p>
<p>その前提知識を踏まえた上で、最近新たに登場した「Swift Build」の立ち位置と可能性について解説されています。<br>
<strong>Swift Buildは、XcodeおよびSPMの両方において「llbuildマニフェストの生成」を行えるツール</strong>です。これにより、機能差の軽減や新たな機能追加が見込まれています。</p>
<hr>
<p>Swiftのビルドシステムの仕組みを、馴染みのない人でも難なく理解できるよう、丁寧に解説されています。<br>
このテーマがここまで分かりやすく解説されるのは希少だと思いますので、ぜひアーカイブが公開されたら視聴をお勧めしたいです。</p>
<hr>
<h3>3. Embedded Swiftで解き明かすコンピューターの仕組み</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.2903%;"><iframe title="Embedded Swiftで解き明かすコンピューターの仕組み | ドクセル" src="https://www.docswell.com/slide/5QX77N/embed" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen></iframe></div>
<p>このセッションは、<strong>Embedded Swift</strong>と<strong>MMIO (メモリマップドI/O)</strong> を使い、OSのないベアメタル環境でコンピューターをゼロから動かす仕組みを紹介しています。</p>
<p>コンピューターの中心には<strong>CPU</strong>があり、機械語で書かれた命令を実行して動作します。<br>
このCPUが実行できる命令セット (ISA) は、画面表示やネットワーク通信といった複雑な機能を直接含んでいる訳ではありません。</p>
<p>画面表示やネットワーク通信といった、周辺機器 (GPUやストレージなど) の制御に使われるのが、<strong>MMIO (メモリマップドI/O)</strong> です。<br>
MMIOは、GPUなどの周辺機器をメモリ上の一領域とみなし、特定アドレスへデータの読み書きを介して、周辺機器をコントロールする技術です。</p>
<p><strong>Embedded Swift</strong>を使用することで、特定のメモリアドレスを直接操作できる、すなわちMMIOが可能となります。Embedded SwiftによるMMIOの実演として、Raspberry Piの画面を操作して、Swiftのロゴを画面に表示するデモが行われました。</p>
<hr>
<p>コンピュータの動作原理の核心に迫る内容で、個人的に非常に面白かったセッションです。<br>
説明が丁寧、かつ実演もあり、低レイヤに詳しくない人でも知的好奇心を満たされる内容かと思います。</p>
<hr>
<h3>4. アセンブリで学ぶCPUアーキテクチャ</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="Learn CPU architecture with Assembly" src="https://speakerdeck.com/player/6220b9f1e63846039dad83abc0dfcba8" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>Intel Macのサポート終了が発表され、Apple Siliconへの完全移行という転換点を迎えた今、<strong>アセンブリ言語を通じて、CPUアーキテクチャの仕組みを学ぼう</strong>というセッションです。</p>
<p>まず、これまでのMacにおけるCPUの歴史を振り返っています。<br>
Macはこれまで、<strong>Motorola 68k (CISC)</strong> → <strong>PowerPC (RISC)</strong> → <strong>Intel x86 (CISC)</strong> → <strong>Apple Silicon (RISC)</strong> のように、命令セット (ISA) が複雑な<strong>CISCアーキテクチャ</strong>と、命令が単純な<strong>RISCアーキテクチャ</strong>の間を行き来してきました。このアーキテクチャ移行を裏で支えてきたのが、Rosettaのようなエミュレーション技術です。</p>
<p>続いて、アセンブリ言語の基礎が解説されています。アセンブリとは、機械語と1対1で対応する低レベルなプログラミング言語です。<br>
このセッションでは、<strong>「Hello, World!」の出力をアセンブリで行うことで、CPUの動作原理を解説</strong>しています。同じ処理でも、 CISC と RISC でアセンブリの記述が変わることも示されました。</p>
<p>最後に、実務的な応用例として、アプリがクラッシュした際のスタックトレースを読む際に、アセンブリの知識がどのように役立つかが紹介されました。</p>
<hr>
<p>3.のセッション (Embedded Swiftで解き明かすコンピューターの仕組み) と同様、コンピュータの動作原理を解説した内容ですが、異なるレイヤーにフォーカスした解説となっています。<br>
両方のセッションを聴講したことで、コンピュータの動作原理をより立体的に理解できました。</p>
<p>アプリ開発をしていると、時たま「あるライブラリがApple Siliconでは動かない」など、CPUアーキテクチャを意識せざるを得ない場面に遭遇するかと思います。そういった場面に備えて、低レイヤーの理解を深める上で良いセッションかと思います。</p>
<hr>
<h2>おわりに</h2>
<p>iOSDC Japan 2025の3日間、弊社ブースへ多くの方々にお立ち寄りいただきました。<br>
アプリのグロースに関する課題感から、KARTEのご紹介まで、皆さんと直接お話しできたことは、私たち開発チームにとって大変有意義でした。</p>
<p>本記事でご紹介したセッションは、私の個人的な興味から低レイヤー寄りの内容が多くなりました。<br>
私と同じくコンピュータサイエンスの探求が好きなモバイルエンジニアの方がいらっしゃいましたら、ぜひカジュアル面談でお話ししましょう！</p>
<p>プレイドでは、以下のポジションで<strong>モバイルエンジニアを積極的に採用</strong>しています。<br>
ご興味のある方は、ぜひリンク先の募集要項をご覧ください。</p>
<ul>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/102069">Mobile App SDK Engineer</a></li>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/106290">アプリエンジニア（新規プロダクト開発）</a></li>
</ul>
<p>最後に、この素晴らしいカンファレンスを企画・運営してくださったスタッフの皆様、そして私たちのブースに足を運んでくださった全ての参加者の皆様に、心より感謝申し上げます。</p>


プレイドは、2025年9月19日〜21日に開催された iOSDC Japan 2025 にゴールドスポンサーとして協賛し、ブース出展も行いました。 本記事では、当日のブースの様子と、聴講した中で特に印象的だった4つのセッションについてご紹介します。

iOSDC Japan 2025参加レポート｜ブース出展の裏側と印象に残ったセッション4選

巨大モノレポ環境でのDeveloper Experience改善に挑戦したプレイドのサマーインターン体験記。CI効率化や社内ESLintプラグイン開発、pnpm catalog移行など技術的成果と、柔軟な労働・開発環境のリアルな様子を詳しく紹介します。

プレイドインターン体験記：巨大モノレポとDeveloper Experienceの改善

「」の記事

Popular Articles

Popular Tags

Archives

Writers