Go Conference 2026 目次 はじめに エブリーのスポンサーブース アンケートボード 食クイズ・くじ引き ノベルティ セッション紹介 Go における FFI のこれまでとこれから cgo とその課題 WebAssembly を使った FFI wasmify と wasm2go 感想 ワークショップ紹介 go.devの歩き方、その先へ 〜Go公式リソースの旅。明日からの調べ方を手に入れるワークショップ〜 参加した理由 ワークショップの流れ 設問2 の調査 ワークショップで得たこと Go × SIMDで高速化するベクトル検索 ~ ルーフラインモデルでSIMDが効く境界を探れ！ SIMDとは GoからSIMDを使う ベンチマークで効果を確認する int8量子化でデータ量を減らす ワークショップを体験して まとめ 非公式アフターイベント Go BASH Vol.3 のお知らせ 最後に はじめに 2026年9月11日(金)に中野セントラルパークで開催された「Go Conference 2026」に今年も参加させていただきました！ 今年も参加レポートとして、会場の様子やセッションの感想についてお届けします！ gocon.jp 今年のテーマは「 Go Far, Go Together 」でした。 Go Far, Go Together このテーマの通り、人との繋がりを重要視していることが強く感じられるカンファレンスだったと思います。 sanposhiho さんのKeynoteセッション「Open Source, Open World」に始まり、 speakerdeck.com コミュニケーションスペースのGo Context Wall、伝Go板、スポンサーブース、難易度別セッション・ワークショップ、そして最後は懇親会と、Goを始めたての人でも、熟練の方でも最初から最後まで楽しめたカンファレンスだったのではないかなと思います。 エブリーのスポンサーブース エブリーは今年は Silver スポンサーとしてブースを出展させていただきました！ 弊社サービスであるデリッシュキッチンをイメージした黄色基調のブースとなっています。 エブリーブース ブースに足を運んでいただいた皆様、本当にありがとうございました！ アンケートボード 昨年に引き続きアンケートボードを用意しました！ 「あなたのGo興味教えてください」というテーマで、Go歴 (Goの利用歴)と気になるトピックが交わる場所にシールを貼っていただきました。 最終結果はこちらです！ アンケート結果 Go歴0〜15年以上の方まで幅広いGopherに回答いただきましたが、Go歴0〜1年の方は設計思想、ある程度経験のある方は最新のGo1.27のトピックに関心が若干寄っているところが面白い部分でした。 またどのGo歴の方もGoとAIに対して関心があり、どんなAI Agentが社内で使われているのか、またどのようにHarnessを作っているのかといった話題についてブースではたくさんお話しすることができました！ 食クイズ・くじ引き 今年から導入した新しいブース企画である、クイズも非常に盛り上がりました！ クイズは食に関する問題2問、Goに関する問題2問の計4問で構成されています。 最終問題のGoの実行結果を答えるクイズで、言語仕様を理解していないと解けなかったり、考えたことがなかったユースケースに対して回答する必要があったりと、難しめに設定しただけあって苦戦している参加者の方も多く見られました。 クイズ ノベルティ 景品は軽量スプーン、まな板、菜箸、しゃもじなど普段の料理で使えるキッチングッズです。 デリッシュキッチングッズ ハズレを引いた方にも、弊社CTOが自らテイスティングして選んだ「CTOブレンド」のコーヒーとステッカーをお渡ししました。 CTOブレンド CTOブレンドの制作秘話については下記を参照ください。 人々へ明るい変化を提供する、オリジナルブレンドコーヒー「every CTO Blend」を制作 キッチングッズが当たった方からは、「最近自炊を始めたのでこれを使って頑張ります」といった感想や、「まさに今欲しかったものなので嬉しいです」といった感想をいただけて運営としても嬉しかったです！ また、このくじ引きで当選したまな板を今でも使っているという方もいたりと、何度もイベントに出展しているとこういうこともあるのかと嬉しくなりました。 セッション紹介 Go における FFI のこれまでとこれから 発表者: goccy さん（株式会社LayerX） レポート: あかがわまさとも スライド: speakerdeck.com 食事管理アプリ ヘルシカ を担当している あかがわまさとも です。私からは、goccy さんの発表「Go における FFI のこれまでとこれから」について紹介させていただきます。 FFI（Foreign Function Interface）は、同一プロセス内で、ある言語で書かれたプログラムから他の言語で実装された機能を呼び出すための仕組みです。本セッションでは、従来の cgo を使う方法とそれに対する課題から、goccy さんによる WebAssembly を活用した新しい方法までを紹介していただきました。 cgo とその課題 スライド 3〜15 ページ FFI での呼び出しは、ABI（Application Binary Interface）という「バイナリ間で関数を呼び出すための約束」に合わせて行う必要があります。Go では、この ABI に合わせた呼び出しを cgo が引き受けています。 発表の序盤では、cgo が抱える課題が3つの観点から整理されていました。 メモリ管理 : Go と C ではメモリの管理が分かれているためメモリリークが起きやすく、C 側でセグメンテーション違反（SIGSEGV）が起きると Go のプロセスごと落ちます。さらに両者はアドレス空間を共有しているので、C 側の不具合で Go 側のメモリを読み書きできてしまいます。 型変換 : 構造体へのポインタや、コールバックのための関数ポインタの受け渡しが複雑になります。相手が C++ だとさらに難しくなります。 開発・デプロイ : C コンパイラが必要になるため Go のクロスコンパイルの手軽さが失われ、Go のプロファイラやデバッガも C 側のコードには使えません。 そのうえで、ポインタのライフサイクル管理、コールバックの実装、静的リンクによるシングルバイナリ化という3つのテクニックが紹介されました。ただしこれらは対症療法で、メモリの管理が分かれていることや C コンパイラが必要になることは、cgo を使う限り変わりません。 普段は Go だけで完結する開発をしているので cgo を書く機会は全くないのですが、課題を詳しく紹介していただき、あまり活用されていない現状や難しさにかなり納得しました。 WebAssembly を使った FFI スライド 16〜23 ページ ここまでの課題を踏まえて、「メモリを安全に扱いたい」「Go のクロスコンパイルの恩恵を受けたい」という動機から WebAssembly（WASM）を使う方法が紹介されました。 WASM モジュールは、自分専用に割り当てられた連続したメモリ領域（リニアメモリ）しか読み書きできないため、ホストとアドレス空間が完全に分離されます。範囲外アクセスはプロセスのクラッシュではなく Go のエラーになります。システムコールも、ホストが許可したものだけが WASI 経由で実行されます。WASI は WebAssembly System Interface の略で、WASM からファイルやネットワークといったホスト側の機能を使うための標準インターフェースです。Go 側は WASM を embed で埋め込み、Pure Go のランタイムである wazero で実行するので、先ほどの課題の多くはここで解消されます。 ただし、C/C++ プロジェクトから WASM を作ること自体が難しく、アドレス空間の異なるホストとのブリッジを書くのも簡単ではありません。cgo なら文字列のアドレスと長さを渡すだけで済むところが、WASM ではリニアメモリ上に領域を確保し、そこにホスト側から書き込む必要があります。安全のために境界を引いた分、その境界をまたぐコードは自分で書くことになります。 wasmify と wasm2go スライド 24〜50 ページ 発表の後半は、この境界を越える手間を減らすために goccy さんが開発したツールの話でした。 wasmify は、C/C++ ライブラリから FFI 用途の WASM とブリッジコードを生成する手順を抽象化した、AI エージェントのハーネスとして利用できるツールです。プロジェクトごとに大きく異なるビルド手順の部分は AI に吸収してもらい、正規化した設定をファイルに残すことで、CI などでは AI なしで同じ結果を再現できるようにしています。非決定的な部分だけを AI に任せ、その結果を固定して冪等性を担保するという設計は、FFI に限らず AI を開発に組み込むときの考え方として参考になりました。 ところが、wasmify で作り直した Pure Go 版の bigquery-emulator（BigQuery のローカルエミュレータ）については、リリースの翌日からパフォーマンス低下の報告が相次いだそうです。あるケースでは 0.6 秒だった処理が 17.3 秒と、約30分の1の速度になっていたとのことでした。この問題への対処として開発されたのが wasm2go で、WASM を Go と Plan9 asm に変換してしまうというアプローチです。メモリが分離されているという WASM の性質は保ったまま、変換後は WASM 由来の実行時の制限を受けないため、最適化の余地が生まれます。 しかし、wasm2go にも課題はありました。たとえば、変換後の Go コードが巨大になるため、そのままではメモリ不足でコンパイルが通らなくなってしまいます。これに対しては、コンパイルの単位を分けて依存関係を直列にし、そこで生じる循環参照を go:linkname で回避するという解決策が取られていました。 go:linkname は、呼びたい関数が定義されている package を import せずにその関数を参照できるコンパイラディレクティブです。ほかの課題への対処も含め、どれも Go の処理系やツールチェーンの挙動を踏まえた解き方で、ここは聞いていて一番面白かったです。 最後に、wasm2go の成果物として go-googlesql や go-python、go-llama といった Pure Go 実装が公開されており、これらを Go から組み合わせて呼び出す Cross Language Binding や、Go のための Agent Sandbox といった応用先も紹介されました。 感想 goccy さんはほぼ毎回 go:linkname の話をされているそうです。発表の本筋ではないですが、今回も後半で循環参照の解消の文脈で登場しました。初めて goccy さんの発表を聞く機会を頂いたのは、今年2月の Go Conference mini in Sendai 2026 でしたが、当時は何のことか分からず困惑した状態で聞いたのを覚えています。 speakerdeck.com 今回はこの go:linkname が何かを知った状態で臨むことができたので、前回よりも楽しく拝聴させていただきました。人の話を聞いて知るきっかけをもらい、前よりも技術を楽しめるようになって、またそこで知らないことを知る。この繰り返しが起きるのが、カンファレンスという場所の素敵なところだなと思います。 goccy さん、興味深い発表をありがとうございました！そして、エブリーブースにも来ていただきありがとうございました！直接感想を伝えられて嬉しかったです！ ワークショップ紹介 go.devの歩き方、その先へ 〜Go公式リソースの旅。明日からの調べ方を手に入れるワークショップ〜 講師: Koki Narumi さん（ANDPAD） レポート: 野村 こんにちは。開発1部でデリッシュキッチンのプレミアム機能を開発している新卒エンジニアの 野村 です。 私はワークショップ「go.devの歩き方、その先へ」に参加しました。 参加した理由 Go 歴は 4 ヶ月ほどです。 Go でわからないことがあったとき、AI に聞いて済ませることもできますが、自分の手で調べた方が理解は深まると感じていました。 AI の回答が間違っている可能性を頭に置きながら進めたり、その回答が正しいかを確かめたりするためにも、公式ドキュメントを調べる力があった方がよいと考えて参加しました。 ベテランの方々が公式ドキュメントをどのように読んでいるのかにも興味がありました。 ワークショップの流れ 当日は andpad-dev/gotan リポジトリの教材に沿って、次の流れで進みました。 リポジトリの説明 初級、中級、上級のレベルごとに分かれて 4 人の班を組む 班ごとに GitHub の Issue を 1 つ持ち、そこに自己紹介を書き込む 班でカテゴリとテーマを選ぶ 設問ごとに 2 人に分かれて調査し、調査結果を Issue に書き込んでいく 答え合わせ 私は Go 歴が浅いので初級を選びました。 カテゴリは次の 4 つから選びます。 Go の標準パッケージ Go の機能や文法構造 Go のコマンド Go の言語仕様、標準ライブラリの実装、設計の背景 私たちの班は「Go のコマンド」を選びました。 初級には 3 つのテーマがあり、その中から go run のテーマ を選びました。 テーマには設問が 3 つあり、私は設問2「go run でビルドされた実行ファイルや $WORK ディレクトリは、実行後どうなるか」を担当しました。 各設問にはヒントと答えが用意されていて、必要になったときに読める形になっています。 設問2 の調査 ここでは、設問2 をどう調べていったかを紹介します。 設問1と設問2はつながっているので、まず設問1にも目を通しました。 最初は手がかりがなかったため、答えに近づきすぎないようにヒントをざっと眺め、そこに書かれていたコマンドをまず実行してみることにしました。 go run -a -x main.go 2 > first.log この -a と -x が何をするフラグなのかを調べました。 調べ方は 03-cmd-tools の README にガイドがあり、それを見ながら進めました。 go help build でも読めますが、今回は pkg.go.dev/cmd/go をページ内検索して確かめました。 -a : すでに最新状態にあるパッケージも強制的に再ビルドする -x : 実行するコマンドを表示する first.log を開くと、1 行目に $WORK ディレクトリのパスが書かれていました。 WORK=/var/folders/bj/1bpczlgx0nxd7gyh6k1gxnhm0000gp/T/go-build2456729570 ここで $WORK に移動しようとしましたが、このディレクトリはすでに存在しませんでした。 cd: no such file or directory: /var/folders/bj/1bpczlgx0nxd7gyh6k1gxnhm0000gp/T/go-build2456729570 first.log の末尾を見ると、実行ファイルを cp している行があったので、そのコピー先に移動してみました（ 班の調査ログ ）。 cp $WORK/b001/exe/main /Users/yuto.nomura/Library/Caches/go-build/96/9677dc4b2f735a2ab8ac9be91e1f1c1ce061dcd1e81e39106ac0b016771e252e-d/main # internal $WORK/b001/exe/main コピー先には main の実行ファイルが残っていました。 つまり $WORK ディレクトリは削除されているが、実行ファイルはキャッシュとして残っている、ということになります。 次に、手詰まりだったのでもう一度ヒントを読みました。 次のようなヒントに注目しました。 go help build のフラグ一覧を眺め、一時ディレクトリに言及しているフラグを探してみましょう。見つけたフラグの説明文を読み、それが「デフォルトでは行われないことを追加で行う」フラグなのか、「デフォルトの動作を止める」フラグなのかを見分けてみましょう。 そこで、再び pkg.go.dev/cmd/go でフラグ一覧を調べました。 すると -work というフラグがあり、「一時作業ディレクトリの名前を表示し、終了時にそれを削除しない」と説明されていました。 この一時作業ディレクトリが、先ほどから調べていた $WORK ディレクトリです。 つまり、 -work を付けないと $WORK は実行後に削除されます。 そこで -work を付けて実行しました。 go run -a -work main.go 今度は $WORK ディレクトリに移動でき、中に実行ファイルがありました。 ここで時間がなくなり、答え合わせの時間になりました。 答え合わせの中で、 -a とキャッシュの関係を理解しました。 次の 2 つのコマンドを実行して比べます。 go run -a -work main.go go run -work main.go -a ありでは $WORK の中に中間ファイルと実行ファイルがありましたが、 -a なしでは $WORK の中は空でした。 答えの中で参照されていた Go 1.24 のリリースノート を読みました。 次のように書かれています。 Executables created by go run and the new behavior of go tool are now cached in the Go build cache. This makes repeated executions faster at the expense of making the cache larger. See #69290. つまり、Go 1.24 から go run でビルドした実行ファイルもビルドキャッシュに保存されるようになった、ということです。 -a を付けると $WORK の中でビルドが実行され、できた実行ファイルがキャッシュに残ります。 -a を付けない場合、ソースに変更がなければビルドを省略してキャッシュ済みの実行ファイルをそのまま実行するため、 $WORK は作られるものの中身は空になります。 以上から、設問2の答えは次の 3 点です。 何もフラグを付けない場合、 $WORK ディレクトリは一時的に作成され、実行が終わると削除される $WORK の中にあった実行ファイルは、ビルドキャッシュのディレクトリに保存される -work を付けると、 $WORK ディレクトリが削除されずに残る ワークショップで得たこと 今回のワークショップでは、 go help と pkg.go.dev を頼りに公式ドキュメントを読み進めることができました。 公式ドキュメントの読み進め方という点では、次のことを意識しました。 go help コマンドを初めて触り、その中身を理解するというステップを踏んだことで、公式ドキュメントを読むことへのハードルが少し下がりました。 公式ドキュメントは翻訳して読んでよいと知ったことでもハードルが下がり、調べやすくなりました。 そのうえで、ページ内検索で公式ドキュメントを検索しながら地道に読んでいくことを意識して取り組みました。 今回のテーマがコマンドツールだったので、コマンドツールの調べ方として意識したこともあります。 go run を実際に動かして観察し、フォルダやファイルが存在するかを確かめたり、フラグを付けて挙動がどう変わるかを見たりしました。 加えて、普段使っているコマンドツールはどのように動いているのだろうと自分なりの仮定を持ってみると、疑問が浮かび、より良い調査ができると感じました。 一次情報を押さえながら進めたので、理解が積み上がっていく感覚がありました。 一次情報にあたる経験に加えて、 go run の仕組みへの理解も深まり、他のコマンドも同じやり方で調べてみたくなりました。 今後 Go を学ぶときにも、この調べ方を使っていきたいです！ Go × SIMDで高速化するベクトル検索 ~ ルーフラインモデルでSIMDが効く境界を探れ！ 講師: Hiromu Nakamura さん レポート: 黒髙 こんにちは、開発本部の 黒髙 です。普段は デリッシュキッチン の開発に携わっています。 私は、 Hiromu Nakamura さんによるワークショップ「 Go × SIMDで高速化するベクトル検索 ~ ルーフラインモデルでSIMDが効く境界を探れ！ ~ 」に参加しました。 このワークショップでは、GoでSIMDを使う方法に加えて、計測結果からボトルネックを見極め、次の高速化手法を選ぶ進め方を学びます。教材本編は、次の流れで構成されています。 ベクトル検索とSIMDの仕組み、Goでの使い方を知る 「ルーフラインモデル」で計算能力とメモリ帯域から性能の上限を考え、マシンの上限を測る スカラ版の全探索を基準として測る（Stage 0） 内積の計算をSIMDで高速化する（Stage 1） int8量子化でデータ量を減らす（Stage 2） 1bit量子化でさらにデータ量を減らし、速度と検索精度の変化を見る（Stage 3） 絞り込んだ候補を元のfloat32で再採点し、検索精度を回復する（Stage 4） 私はStage 2まで取り組みました。ここでは、SIMDの機能と、実際に確認できた高速化の効果を中心に紹介します。 資料と教材は以下で公開されています。 speakerdeck.com github.com 題材は、384次元のベクトル10万件から、クエリとの内積が大きい上位10件を探す処理です。ベクトル検索では、文章などを数値の並びで表し、その近さを使って検索します。 SIMDとは SIMD （Single Instruction, Multiple Data）は、1つの命令で複数のデータに同じ演算を適用するCPUの機能です。その働きを、今回のワークショップで扱う内積計算を例に見てみます。 内積は、2つのベクトルの同じ位置にある要素を掛け合わせ、その結果をすべて足す計算です。8要素のベクトルなら、次のようになります。 a = [1, 2, 3, 4, 5, 6, 7, 8] b = [2, 3, 4, 5, 6, 7, 8, 9] 内積 = 1×2 + 2×3 + 3×4 + 4×5 + 5×6 + 6×7 + 7×8 + 8×9 = 2 + 6 + 12 + 20 + 30 + 42 + 56 + 72 = 240 Goで素直に書くと、次のようになります。 var sum float32 for i := range a { sum += a[i] * b[i] } このループでは、 a[i] と b[i] を1組ずつ掛け、その結果を1つの変数 sum に足していきます。8要素なら、この処理を8回繰り返します。このように、演算で値を1要素ずつ扱うのが スカラ処理 です。 一方、8要素を扱えるSIMD命令なら、 1×2 から 8×9 までの掛け算をまとめて実行できます。掛け算の部分に注目すると、スカラ命令では8回かかるところを、SIMD命令なら1回で処理できます。掛け算命令の実行回数は1/8です。 SIMDで8組の掛け算を1命令で実行し、結果を合計して内積を求める模式図 図1：SIMDで8組の掛け算をまとめて実行し、その結果を合計して内積を求めます。 どちらも8組の掛け算を行いますが、SIMDではそれを1つの命令にまとめられます。SIMDでまとめて掛けた結果は [2, 6, 12, 20, 30, 42, 56, 72] という8個の値なので、内積を得るには最後にこれらを合計する処理が必要です。 このように、同じ演算を大量の要素に繰り返す処理で、1命令あたりに処理できる要素を増やせることがSIMDの便利な点です。今回の検索では、384要素の内積を10万件のベクトルに対して繰り返すため、SIMDによる高速化が期待できます。SIMDは1つのCPUコアの中でも利用できる仕組みです。 GoからSIMDを使う Go 1.27では、実験的なパッケージ simd/archsimd を使い、Goの型やメソッドでCPU固有のSIMD演算を扱えます。 archsimd 自体はGo 1.26で導入され、1.27ではAPIの改訂やarm64・WebAssemblyへの対応が追加されています。まだAPIは安定しておらず、ビルド時に GOEXPERIMENT=simd を指定して有効化します（ Go 1.27リリースノート ）。 CPUには、計算中の値を置く レジスタ という小さな記憶領域があります。今回のamd64向け実装では、256bit幅のSIMDレジスタを利用します。 float32 は1個32bitなので、1つのレジスタに8個の値が入ります。この1要素ぶんの区画を レーン と呼びます。 Goでは、この「32bitの値を8レーン」という形を archsimd.Float32x8 という型で表します。先ほどの図と同じく、8要素をまとめて扱えます。次のコードは、384要素ある a と b のうち、先頭8要素を処理する部分を示したものです。 var acc archsimd.Float32x8 // 8レーンとも初期値は0 va := archsimd.LoadFloat32x8(a) // aの先頭8要素を読む vb := archsimd.LoadFloat32x8(b) // bの先頭8要素を読む acc = va.MulAdd(vb, acc) // 各レーンでva×vbをaccへ足す LoadFloat32x8 は、スライスから8要素を読み込む関数です。 va と vb にはそれぞれ8個の値が入り、 acc にも途中結果をためる場所が8個あります。 va.MulAdd(vb, acc) では、各レーンで「 va の値 × vb の値 ＋ acc の値」を計算します。 MulAdd は、掛け算と足し算をまとめて行うFMA（Fused Multiply-Add）に対応します。 Float32x8 では、この積和演算を8レーンまとめて1つの命令で行います（ MulAddのドキュメント ）。 a と b の読み込む位置を進めながら同じ処理を繰り返すと、各レーンに積和の途中結果をためていけます。最後にレーンごとの値を合計すると、内積が求まります。 このようなSIMD命令を、アセンブリやcgoを自分で書かずに、Goの型やメソッドを通して利用できるのが archsimd の特徴です。 ベンチマークで効果を確認する ここからは、冒頭で紹介したStage 0（スカラ版の計測）→Stage 1（SIMD化）の流れに沿って、実際の効果を見ていきます。まず make bench0 でスカラ版の全探索の速度を測り、続く make bench1 でスカラ版とSIMD版を比較しました。 計測には、ワークショップで用意された教材のGitHub Codespaces環境を使いました。実行環境はLinux / amd64で、CPUはAMD EPYC 7763でした。 教材には、内積単体を測るベンチマークと、10万件すべてとの内積計算から上位10件の選択までを含む、検索全体のベンチマークがあります。SIMD版も全件を走査する流れは同じで、内積の計算をSIMDに置き換えています。実装では途中結果をためる変数を acc0 と acc1 の2本に分け、互いの結果を待たずに計算できるようにしています（ 教材の内積の実装 ）。 8要素をまとめて計算できても、処理全体がそのまま8倍速くなるとは限りません。以下は、 make bench1 で内積単体と検索全体を計測した結果です。 計測対象 スカラ版 SIMD版 高速化の倍率 float32の内積 393.8 ns 58.71 ns 約6.7倍 10万件の検索 36.10 ms 9.76 ms 約3.7倍 内積単体では約6.7倍、検索全体でも約3.7倍の高速化を確認できました。 内積単体の改善が、そのまま検索全体の倍率になるわけではないことが分かります。検索ではベクトルの読み込みも必要で、計算だけを速めても読み込みが追いつかなければ、CPUはデータを待つことになります。こうした性能の上限を考えるために、スライドではルーフラインモデルが紹介されていました。 Go × SIMDで高速化するベクトル検索 ~ルーフラインモデルでSIMDが効く境界を探れ！ ~ - Speaker Deck この図は、横軸が算術強度、縦軸が1秒あたりの演算回数で、屋根の形をした線が性能の上限を表しています。 算術強度は「演算回数／バイト」、メモリ帯域は「バイト／秒」なので、両者を掛けると「演算回数／秒」になります。これが、メモリからのデータ供給によって決まる性能の上限です。 線が折れ曲がる点（リッジ）より左側では、算術強度 × メモリ帯域 ＜ 演算ピークとなります。CPUの計算能力より、データを供給する速さが低い上限を作るため、この領域の上限はメモリ帯域によって決まります。算術強度を上げると、同じ転送量でできる計算が増えて上限も上がるため、グラフは右上がりの斜線になります。 リッジより右側では、算術強度 × メモリ帯域 ＞ 演算ピークとなるため、CPUの計算能力が性能の上限を決めます。算術強度をさらに上げてもこの上限は変わらないので、グラフは水平になります。実際の計測点がこの線より下にある場合は、SIMDなどで計算を効率化し、上限に近づけられる可能性があります。 int8量子化でデータ量を減らす メモリから読み込めるデータ量には1秒あたりの上限があるため、同じ件数のベクトルでもデータ量が少なければ読み込みにかかる時間を短くできます。この読み込み時間を減らして検索を速めるのが、Stage 2（int8量子化）です。 この段階では、 make bench-int8 でint8量子化を使った実装を計測しました。量子化は、値を少ないビット数で近似して表す方法です。float32をint8に変換すると、走査するベクトル本体は153.6 MBから38.4 MBになります。 検索全体の時間は、Stage 1のfloat32 SIMD版の約9.76 msから、int8 SIMD版の約4.00 msへ短縮され、さらに約2.4倍速くなりました。量子化によるデータ量の削減と、int8向けのSIMD計算を組み合わせた効果です。 int8の内積単体でも、スカラ版の412.8 nsからSIMD版の32.17 nsへ、約12.8倍の高速化を確認できました。 ただし、量子化は値そのものを変えるので、全探索をしても、検索結果が正解とずれる可能性があります。そのため、教材ではRecall@10（正解の上位10件と何件一致したか）という指標を用いて、検索結果の精度も検証していました。この評価では、元のfloat32版で得られた上位10件を正解としています。 ワークショップを体験して 今回のワークショップでは、Goの実験的なSIMDパッケージを使い、ベクトル検索を段階的に高速化する方法を学びました。ルーフラインモデルで計算能力とメモリ帯域の制約を考えながら、SIMDによる内積の高速化から、量子化によるデータ量の削減へと進む流れでした。資料では、さらに1bit量子化と再採点を組み合わせて、速度と検索精度の両立を目指すところまで紹介されていました。 Goのコードを動かして内積や検索が速くなる様子を確かめ、SIMDによる並列化の恩恵を感じることができました。さらに、量子化でデータ量を減らすといった高速化の手法にも、手を動かしながら触れられてよかったです。 まとめ Go Conference運営の皆さん、今年もカンファレンスを開催していただきありがとうございました！ 昨年との違いとして気づいたのは、今回はGo Conferenceだけでなく「DroidKaigiで弊社を見かけた」、「iOSDCにも参加予定」といったエンジニアの方が多数みられたことです。 DroidKaigi のアンケートでもある通り、どの企業様のエンジニアも越境する意識があるのだなと感じさせられました。 今年もたくさんのGopherとお話したり、セッションを拝聴したりと充実した1日を送ることができました！ Go Conference 2027もぜひ参加したいです！ 非公式アフターイベント Go BASH Vol.3 のお知らせ ANDPAD、OPTiM、Resilire、エブリーの4社合同で、非公式アフターイベント Go BASH Vol.3 を開催します！ 2026年9月30日(水) 19:30〜、会場はエブリー本社です。Go Conference 2026 の感想戦や各社のセッションを用意していますので、ぜひご参加ください！ connpass.com 最後に エブリーでは、ともに働く仲間を募集しています。 テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！ corp.every.tv 最後までお読みいただき、ありがとうございました！

はじめに さくらのナレッジ編集部の法林です。 2026年8月1日(土)に、さくらインターネットの大阪本社でもあるBlooming Campにおいて「きのこカンファレンス 2026 in 関西」が行われました。本記事ではこ […]

本ブログは 2025 年 8 月 4 日に公開された Amazon Science Blog “ Three challenges in machine-based reasoning ” を翻訳したものです。 自然言語から構造化された言語への変換、真理の定義、そして確定的な推論は、自動推論において依然として中心的な課題です。しかし、Amazon Web Services の新しい自動推論チェック (Automated Reasoning checks) は、これらすべてに対処するのに役立ちます。 生成 AI の登場により、自動推論の分野に携わってきた私の 30 年以上のキャリアの中で、ここ数年は最も刺激的な時期になっています。なぜでしょうか。コンピュータ業界、さらには一般の方々までもが、論理の分野に携わる私たちが長年情熱を注いできたアイデアについて、今や熱心に語るようになったからです。言語、構文、意味論、妥当性、健全性、完全性、計算複雑性、さらには決定不能性といった課題は、かつては学術的で難解すぎて、多くの人々には縁のないものでした。しかし、状況は一変しました。これらのテーマに触れ始めたばかりのみなさん、ようこそ。ぜひ足を踏み入れてください。一緒に取り組めることを楽しみにしています。 本記事では、AI システム (例えばチャットボットのような生成 AI ベースのシステム) で正しい推論を実現する際に、最も厄介だと私が考える 3 つの側面を紹介します。Amazon Bedrock Guardrails の自動推論チェック機能をリリースした背景には、まさにこれらの難題がありました。とはいえ、まだ道半ばです。これらの問題には本質的な難しさがあるため、私たちはコミュニティとして (そして自動推論チェックのチームとして)、この先も長年にわたってこれらの難題に取り組み続けることになるでしょう。 難題 1: 自然言語から構造化された言語への変換 人間は通常、厳密さに欠けるあいまいな言葉でやり取りしています。多くの場合、文脈からあいまいさを解消する情報を補って理解できます。本当に重要な場面では、「～という意味でしょうか」と互いに確認し合うこともあります。しかし、本当に確認すべき場面であっても、そうしないこともあります。 これはしばしば混乱と対立の原因になります。ある雇用主が、従業員向け福利厚生の受給資格を「フルタイム換算 (FTE) 0.2 以上の雇用契約を有していること」と定義しているとしましょう。ここで私が「手術を受けた家族の回復を支えるために昨年休みを取った期間を除き、自分の時間の 20% を仕事に費やしています」と伝えたとします。私はこの福利厚生を受ける資格があるでしょうか。「自分の時間の 20% を仕事に費やしている」という発言は、雇用契約のもとで、労働時間の 20% に相当する時間を働いているという意味なのでしょうか。 私の発言には複数の合理的な解釈が成り立ち、解釈によって受給資格の結論が変わります。自動推論チェックでは、相補的ないくつかのアプローチを用いて、自然言語とクエリ述語の間の変換を複数回試みます。これはインタビューでよく使われる手法と同じです。同じ情報を異なる方法でたずね、事実が一貫しているかどうかを確かめるのです。自動推論チェックでは、形式論理体系のソルバーを使って、異なる解釈が等価であるかどうかを証明または反証します。変換結果が意味のレベルで食い違っていれば、自動推論チェックを利用するアプリケーションは、ユーザーに確認を求めることができます (例: 「フルタイムの 20% 以上の雇用契約があることを確認していただけますか」)。 自動推論チェックは、大規模言語モデルを使用して、自然言語を形式言語へ変換した複数の候補を生成します。変換結果の間に食い違いがあれば自動推論チェックがそれを指摘し、お客様は自然言語による対話を通じて解消できます。 難題 2: 真理の定義 いつも驚かされるのは、ルールの意味について複数の人が合意することがいかに難しいかという点です。複雑なルールや法律には微妙な矛盾が潜んでいることが多く、誰かがその解釈について合意を形成しようとするまで見過ごされることがあります。例えば、英国の 1988 年著作権・意匠・特許法 (Copyright, Designs and Patents Act 1988) には本質的な矛盾があります。著作権の対象となる著作物を著作者自身の知的創作から生じたものと定義する一方で、人間の創造的な関与を必要としない著作物にも保護を与えているのです。この不整合は、AI が作品を生成する現代において、とりわけ目立つものになっています。 2 つ目の問題は、私たちがルールを絶えず変え続けているように見えることです。例えば、米国連邦政府の日当 (per diem) の額は毎年変更されるため、その値に依存するシステムは常に保守が必要になります。 最後に、自分が従うべきルールのコーナーケースをすべて深く理解している人はほとんどいません。運転中のイヤホン装着を例に考えてみましょう。米国では、アラスカ州のように違法な州、フロリダ州のように片方のイヤホンだけなら合法な州、そしてテキサス州のように問題なく合法な州があります。友人や同僚に非公式に聞いてみたところ、直近で車を運転した場所において、運転中のヘッドホン装着が合法かどうかを自信を持って答えられた人は、ごくわずかでした。 自動推論チェックは、税法、人事ポリシー、その他のルール体系といったお客様の関心領域において何を真理とするかを定義できるよう支援し、さらにルールの変更に合わせてその定義を継続的に洗練する仕組みを提供することで、これらの難題に対処します。生成 AI ベースのチャットボットが登場したとき、私たちの多くが想像力をかき立てられたのは、複雑なルール体系を自然言語のクエリで一般の方々にも利用できるようにする、という発想でした。将来、チャットボットは「日本の東京で運転中に U ターンできますか」といった質問に、端的でわかりやすい回答を返せるようになる可能性があります。真理を定義するという難題に取り組むことで、自動推論チェックはその回答の信頼性を確保するのに役立ちます。 自動推論チェックのユーザーインターフェイス。 難題 3: 確定的な推論 ルールの集合 (これを R と呼びます) と、検証したい文 ( S ) があるとします。例えば、 R はシンガポールの交通規則、 S はシンガポールの交差点での U ターンに関する質問だとしましょう。 R と S は、ブール変数をさまざまに組み合わせることで、コンピュータが理解できるブール論理へエンコードできます。 R と S のエンコードに必要なのはわずか 500 ビット、およそ 63 文字だとしましょう。ごく小さな情報量です。しかし、ルール体系のエンコードがテキストメッセージに収まるほど小さくても、チェックすべきシナリオの数は天文学的な規模になります。理論上は、2 500 とおりの組み合わせをすべて検討しなければ、 S が真であると断定することはできません。今日の高性能なコンピュータは、まばたきをする間に数億回の演算を実行できます。しかし、世界中のコンピュータをこの猛烈な速度で宇宙の始まりから動かし続けていたとしても、2 500 とおりの可能性をすべてチェックし終えるには、今日に至ってもなお程遠いでしょう。 ありがたいことに、自動推論のコミュニティは SAT (充足可能性問題) ソルバーと呼ばれる高度なツール群を開発してきました。これによって、この種の組み合わせのチェックが可能になり、すべてではないものの、多くのケースで驚くほど高速に実行できます。自動推論チェックは、文の妥当性を検証する際にこれらのツールを活用しています。 残念ながら、あらゆる問題を SAT ソルバーの強みが生きる形でエンコードできるわけではありません。例えば、あるルール体系に次の規定があるとしましょう。 「2 より大きいすべての偶数が 2 つの素数の和であるならば、源泉徴収税率は 30% とし、そうでなければ 40% とする」 。問題は、源泉徴収税率を知るには 2 より大きいすべての偶数が 2 つの素数の和であるかどうかを知る必要があるのに、それが真かどうかを現時点で誰も知らないという点です。この命題はゴールドバッハ予想と呼ばれ、1742 年以来の未解決問題です。とはいえ、ゴールドバッハ予想の答えはわからなくても、それが真か偽のいずれかであることは確かです。したがって、源泉徴収税率は 30% か 40% のいずれかでなければならない、と確定的に言えます。 自動推論チェックを利用するお客様が、自動推論チェック自身の判定結果に依存するポリシーを定義できるかどうかを考えてみるのも面白いところです。例えば、次のルールをポリシーとしてエンコードすることは可能でしょうか。 「アクセスは、自動推論チェックが『許可されない』と判定した場合、かつその場合に限り許可される」 。この場合、正しい答えは存在しません。このルールは自身のチェック手続きを再帰的に参照することで矛盾を生み出しているからです。ここでできる最善の対応は「不明 (Unknown)」と答えることです (実際、このケースで自動推論チェックが返す答えも「不明」です)。 訳注: 2026 年 9 月時点の Amazon Bedrock ユーザーガイドでは、自動推論チェックの検証結果は VALID、INVALID、SATISFIABLE、IMPOSSIBLE、TRANSLATION_AMBIGUOUS、TOO_COMPLEX、NO_TRANSLATIONS の 7 種類として定義されており、「不明 (Unknown)」という結果値はありません。ポリシーの矛盾により判断できない場合は IMPOSSIBLE が返されます。参照: 自動推論チェックの概念 – Amazon Bedrock 自動推論チェックのようなツールが、こうした文に対して「真」も「偽」も返せないという事実は、1931 年に Kurt Gödel によって初めて示されました。Gödel の結果からわかるのは、自動推論チェックのようなシステムは無矛盾性と完全性を同時に満たせず、どちらかを選ばなければならないということです。AWS は無矛盾性を選びました。 自然言語を構造化された論理へ変換すること、絶えず変化し、時には矛盾するルールのもとで真理を定義すること、確定的な推論の複雑さに立ち向かうこと。この 3 つの難題は、健全な推論を備えた AI システムを構築する際に直面する単なる技術的ハードルにとどまりません。いずれも、私たちの技術の限界と、人間が作る仕組みの複雑さの両方に深く根ざした問題です。 2025 年 8 月 6 日の Amazon Bedrock Guardrails における自動推論チェックのリリースを機に、AWS は相補的なアプローチを組み合わせてこれらの難題に取り組んでいます。具体的には、あいまいな自然言語から論理述語へ変換するためのクロスチェック手法を適用すること、お客様によるルール体系の開発と保守を支援する柔軟なフレームワークを提供すること、そして確定的な回答が得られないケースを慎重に扱いながら高度な SAT ソルバーを活用することです。これらの難題に対する製品の性能を高めていく中で、AWS は技術を前進させるだけでなく、Gödel の不完全性定理から、変化し続ける法律やポリシーの枠組みのあり方に至るまで、推論そのものを形作ってきた根本的な問いへの理解も深めています。 健全な推論を提供するというコミットメントを踏まえれば、AI 分野における今後の道のりは険しいものです。その挑戦を受けて立ちます。 著者について Byron Cook Amazon の vice president 兼 distinguished scientist である Byron Cook は、形式的検証分野のリーダーであり、SAT、SMT、記号モデル検査への貢献と、それらを生物システム、コンピュータのオペレーティングシステム、プログラミング言語、セキュリティへ応用した実績で知られています。Byron が Amazon で進めてきた自動推論の取り組みは、クラウドにおけるより高い水準の保証と、お客様向けの新機能の実現につながっています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。