2022年振り返りと2023年予想
今年個人的に心に残った技術と来年盛り上がりそうなキーワードをつらつら書きます。
「2022年予想」の振り返り
前回「TechRepot 2021.12」での2022年予想をふりかえってみます。
CDNエッジコンピューティング
Cloudflareを爆心地として、開発環境がものすごい勢いで整ってきています。
ひとつ代表的な動きをあげると、Honoというウェブフレームワークが立ち上がりました。HonoはCloudflare WorkersやFastly Compute@EdgeなどCDNエッジコンピューティング環境を前提としています。複数の環境で動くのは、どちらもService Worker APIというWeb標準規格に乗っかっているからです。
CDNプラットフォーム側からの道具もたくさん登場し、実行基盤としてはVercel Edge Functionsが正式リリースされたほか、今回利用したCloudflare R2の一般提供や、Cloudflare Pub/Subのプライベートベータなど、Cloudflareの存在感が依然として強くなっています。
CDNは、今後数年ずっとアプリケーションの開発体験の最前線でありつづけるでしょう。
イベントバス
イベントの変形などイベントバスの多様化を予想していましたが、まさにそこを大きく拡充するものがAmazon EventBridge Pipesです。AWS Lambdaで利用されている「Event Source Mapping」という仕組みをソースとして、StepFunctionsのように、フィルタリングや外部呼び出しによるイベントデータの強化（enrichment）ができる、小さなオーケストレーション基盤です。
StepFunctionsのようなオーケストレーションの管理と、EventBridgeなどを利用したコレオグラフィ（誰かが全体を統括するのではなく責務を分担する）の構成管理で、両極端になっていたので、その間を埋めてくれるものとしてよくできています。
昨年の繰り返しになりますが、イベント駆動アプリケーションで疎結合と管理性を両立することが設計における一番の関心事といえるでしょう。そのひとつとしてイベントバスを中心とした機能拡充は今後も注目していきます。
WebAssemblyとeBPF
WebAssemblyは完全に普及期に入りました。たとえばAmazon Prime Videoが再生品質を上げるために動画再生プレイヤーとしてWebAssemblyを採用しました。
WebAssemblyでは、WASIという共通インターフェースが仕様化されています。このWASIへのサポートが上下それぞれ進んでいます。Cloudflare WorkersはWASIに基づいてWebAssemblyに対応した一方で、DockerもWasmEdgeというランタイムを利用してWebAssemblyに対応しようとしています。WasmEdgeもWASIに対応しています。CDNエッジコンピューティングの領域でWebAssembly/WASIが一般的になるのであれば、開発環境としてDockerがそこに対応しようというのは当然でしょう。そして、WASIの上側では、Ruby 3.2.0ではWASI上でCRubyが動くようになりました。PostgreSQLなども移植が試みられています。
eBPFはKubernetesのデータプレーン制御やモニタリング、セキュリティ統制など、淡々と推進されていますね。こちらも、万人が触る領域ではありませんが、今後誰もが見えないところでお世話になり続ける技術となっています。
Decentralizedな世界
今年、とても分かりやすく幻滅期に入った技術と言えるでしょう。とはいえ技術そのものの面白さが陰ったわけでは無く、投資先としての過剰な期待が醒めたという状況です。
というわけで、ここからは来年注目したいキーワードを取り上げていきます。
ジェネラティブAI
今年はこのキーワードを抜きに語ることはできないでしょう。
夏にMidjourneyやStable Diffusionが公開されるとともに、複雑な呪文を組み合わせて成果を得る「AI絵師」というジャンルが生まれました。年末には「いらすとや」さんと提携により追加学習したモデルを使った「AIいらすとや」がリリースされ、街のいらすとや支配が一層進みそうな気配がします。
その一方で、ライセンスに関する課題も大きな話題になりました。モデルの学習に利用したデータの著作権の扱いは、国によって大きく異なります。日本はかなりデータの利活用に重きを置いています。その一方で、学習したモデルの利用者はインターネットでグローバルなわけですし、たとえ法律がゆるしても「筋」を通さねば感情が許さない、という面があるのもまた事実です。またディープフェイクのようなものからどうやって人を守っていくかも重要です。
AIが無双しているのは芸術だけでは無く、我々ソフトウェアエンジニアの領域でもです。公開されたソースコードを学習して、コードの「補完」を行うGitHub Copilotはついに正式サービスとなりました。GitHub Copilotのモデル学習に関するライセンス処理は、米国のフェアユースを根拠にしていると主張していますが、集団訴訟が提起されているためこの判決を見届ける必要がありそうです。
より一般的なものとして年末に登場したのが、自然な会話で広い知識に基づいた分かりやすい回答ができるチャットボット、ChatGPTです。こちらも公開されたソースコードなどを学習しているようで、お願いするとソースコードを書いてもらうこともできます。コードレビューや脆弱性診断に使えないかという試みも行われています。
2025年には全データの10％がAIによって生成されると予測されています。そのとき人類はなにを責務として担っているでしょうか。
開発環境のクラウド化
GitHubに組み込まれたオンラインIDEであるGitHub Codespacesを、無料プランの個人ユーザーでも利用できるようになりました。対抗するGitLabもこれまで提供していたWebIDEから、VSCodeベースの新しいものに移行し、ターミナルからのコマンド実行なども可能になります。Google CloudからもCloud Workstationsを提供しました。
どれもVSCodeやJetBrainsの機能としてリモートバックエンドに対応したことで実現したもので、俊敏な反応が求められる画面処理はローカルPC上で、実際のファイル操作やプログラム実行のみをリモートで走らせる、ということが様々な組み合わせで現実的になりました。
IDEの最大手JetBrainsは、このリモートバックエンドを前提とした軽量なコードエディタJetBrains Fleetの開発を進めています。VSCode一強となりつつある昨今ですが、IntelliJの開発体験を知っているとこちらも楽しみです。
ウクライナ侵攻の影響
今年最大の事件はロシアによるウクライナ侵攻でした。
ソフトウェア業界も無関係では居られず、いくつかのできごとがありました。
当初モスクワに在住していた開発者が中心となっていたNGINXは、現在はネットワーク機器ベンダーF5 Networksに買収されていますが、ウクライナ侵攻を受けて開発陣をモスクワから他の地域に移転させています。
コンピュータセキュリティ企業のカスペルスキーはロシアの企業ですが、ウクライナ侵攻を受けて米国の脅威リストに載るなどの扱いを受け、透明性への取り組みに力を入れています。
ロシアに対する「制裁」としてインターネットやその上のサービスの遮断を求める声も強く上がっています。それに対して、インターネット基盤に関するポリシーなどを議論するISOCから、インターネットからの締め出しはするべきではない、世界の動向を市民に伝える機会を失いかねない、とする声明を出しています。
グローバルで唯一なインターネットが今の姿で居られるのは、様々な人の不断の努力によるものです。私はそういった姿勢を支持します。
衛星通信のコモディティ化
ばんばん衛星を打ち上げまくっているStarlinkのおかげで、衛星通信がコモディティ化しつつあります。ウクライナにおいてStarlinkを活用した活動が話題になっていましたが、日本でもついにサービスが開始されました。月額1.23万円と、ちょっと高いインターネット回線として「ネタ代」と考えれば十分にお釣りが来そうな価格レンジです。
iPhone 14では、Globalstarによる衛星通信を利用したSOS発信機能が搭載されました。
どちらも低軌道衛星（LEO）をたくさん組み合わせて使う衛星コンステレーションというシステムで実現されています。一般的に想像される静止衛星では高度3万キロメートル以上と遠くにあるので、数百ミリ秒の遅延がどうしても発生してしまいます。低軌道衛星を介する衛星コンステレーションでは、数十ミリ秒と一桁少ない遅延に抑えることができます。
iPhoneの衛星通信はあくまでSOSに特化しているため、いくつかの選択肢のなかから選んだSOS内容を送るだけのものですが、スマートフォンのサイズのデバイスから衛星に届けられるというのは純粋にすごいです。
こういった技術は、いったん使われ始めるとどんどん利用が加速していって急速にコモディティ化することが多く、5年後くらいには当たり前の技術になっているかもしれません。
うるう秒の廃止
地球の自転にかかる時間は様々な要因で変動するので、天文学的な観測結果とのすりあわせを行うために用いられるのがうるう秒です。
うるう秒は、基本的には1月と7月にあることになっていますが、あくまで観測結果に基づくため遠い未来の予測はできず、半年前にうるう秒が挿入されるかが決定されるという仕組みになっています。そのため、未来の「時刻」は厳密には確定できません。コンピュータシステムで広く使われているＵnix timeでは、うるう秒は「なかったもの」とみなすことで、この問題を回避しています。
その一方、現実世界ではたしかにうるう秒は挿入されたり削除されたりするため、うるう秒前後の時刻をどう表現するか、様々な異なるやり方が生まれてしまいました。あるシステムは、59秒99の次は59秒00から1秒間を繰り返しますし、別のシステムは前後1時間かけて少しだけ時計をゆっくり進めることでうるう秒を「吸収」しようとします。
人類がおおらかな時代であればこれでもよかったのですが、いまや1秒以内の時刻の違いが重要となる場面が確かに存在し、そういったシステムで異なるやり方が混在すると不具合が発生します。
そのため、ＩＴ業界を中心にうるう秒の廃止を求めていましたが、ついに廃止の方向で決定しました。わーい！
地球の自転が早くなっているという観測結果もあり、これが一時的なものでないとすると、「負のうるう秒」と直面していただけにありがたいことです。
SBOM：ソフトウェアコンポーネント部品表
2021年に米国連邦政府が義務条項を打ち出したことをきっかけに、製品に含まれるソフトウェアコンポーネントについて、そのライセンスや依存関係などを明らかにするSBOMと呼ばれる考え方が必要となりました。
これまで、ソフトウェアセキュリティの現場では、たとえばOSのパッケージシステムやnpm、Ruby Gemなどライブラリの構成情報をもとにスキャンを行う、VulsやOpenVASといったツールが利用されていました。またnpm auditやFreeBSD pkg auditのようにエコシステムそのものに脆弱性データベースを持ちチェックができるものもあります。
セキュリティに限らずより汎用な枠組みとして、ライセンス管理や調達の管理など、製造業が普通にやっているように部品表として管理をしていこう、というものです。
ＬＬ言語であれば、実行環境にそのままライブラリのファイルがあるので運用段階からＳＢＯＭにすることも比較的容易ですが、コンパイル型の言語であれば、あとから静的リンクされた中身を整理することは容易ではありません。開発プロセスにきちんと組み込んでいく必要があります。
SBOMはまだ未成熟の分野で、フォーマットが複数あったり、現実的にどのように運用するかなど、課題が多くなります。ですが、1年後には間違いなく様々な試みが進んで活用が当たり前となっていく分野でしょう。