こんにちは、Researchチームのアマニと福原です。 先週、キャディ（CADDi）はECCV2026に参加し、企業紹介や研究内容に関するポスターを発表してきました。弊社としては、初めての国際学会でのポスター発表となりました。 今回は国際ワークショップのスポンサーとして参加し、以下の2つのワークショップをオーガナイズしました。 FOUND: Foundation Data for Industrial Tech Transfer Foundation Modelを実世界の産業領域で活用する上で必要となる、ドメイン固有のデータや技術移転をテーマとしたワークショップです。特に、Foundation DataやPhysical AI、World Modelに焦点を当て、研究成果を実際の現場につなげるための課題が議論されました。 LIMIT : Representation Learning with Very Limited Resources 限られたデータやラベル、計算資源などの制約下で、どのように効果的な表現学習を実現するかを扱うワークショップです。自己教師あり学習やFew-shot Learning、Synthetic Dataなど、限られたリソースを前提としたさまざまなアプローチが議論されました 本記事では、ワークショップ運営の経験やECCVに参加した感想、気になった論文・発表についてレポートします。 ECCVとは ワークショップについて FOUND Workshop The Path to Manufacturing: Evolving 3D Generation to Intelligent Computer-Aided Design 特に印象に残った発表 MolmoPoint: Better Pointing for VLMs with Grounding Tokens DreamCAD: Scaling Multi-modal CAD Generation using Differentiable Parametric Surfaces Steerable Visual Representations Make Geometry Matter for Spatial Reasoning Understanding Geometric Representations in Self-Supervised Vision Transformers via Subspace Intervention MeshFM: 2D Features Are All You Need for 3D Shape Understanding Yann LeCun氏のKeynote「World Models:Enabling the Next AI revolution」 まとめ ECCVとは ECCV（European Conference on Computer Vision）は、CVPR、ICCVと並ぶ、コンピュータビジョン分野の主要な国際会議の一つです。2年に一度開催され、今年はスウェーデンのマルメで開催されました。世界中から研究者やエンジニアが集まり、会場では数多くの研究発表やワークショップ、ポスターセッションなどが行われていました。 ECCVでは、画像認識・生成、3Dビジョン、マルチモーダル学習、Vision-Language Model（VLM）など、コンピュータビジョンに関する幅広い研究が発表されます。 ECCV2026の会場 今年の本会議(main conference)では、ワークショップを除いても2,800本を超える論文が採択されており、特にPhysical AIやWorld Modelへの注目度が高かった印象でした。 今回の参加では、キャディで取り組んでいるテーマとの関連性を意識しながら、CAD・B-Rep・3D・空間把握・VLMの解釈性などの研究を中心に見て回りました。 ワークショップについて 本章では、キャディがオーガナイズしたFOUNDワークショップの運営経験と、普段取り組んでいる研究テーマに関連するワークショップ「The Path to Manufacturing」を中心に紹介します。 ワークショップのポスターセッションで発表したキャディの研究紹介ポスター FOUND Workshop 基盤データと産業応用を中心的なトピックとしたワークショップで、ICCV 2025に続いて2回目の開催で今回も福原がPrimary Organizerを担当しました。基盤モデルはCVを大きく前進させましたが、実世界のドメイン固有な運用に持ち込むと、long-tailな分布、domain shift、プライバシーや安全性やコストといった制約によって、期待したほどの信頼性が出ません。この"last-mile"を埋めるために必要なドメイン特化のデータの集合を基盤データ（Foundation Data）と呼んでいます。 FOUNDワークショップのフライヤー Opening Remarksでは、1年前の第1回で投げた問い「Are we fully delivering the value of foundation models across industries?（私たちは基盤モデルの価値を、産業のすみずみまで届けられているだろうか）」を、もう一度投げるところから始めました。同じ問いでも、この1年で足元の地面は動いています。私たちが取り組んでいるCADの領域でも、MLLMを使用して1年前とは比べものにならない精度で、図面から3D CADを起こすことができるようになりました。ただし産業の尺度で測ると話は変わり、直前に公開されたRealCADBenchというベンチマーク（プレプリント）では、コードが実行できる割合が57〜81%ある一方で、Surface IoUは11〜22%にとどまります。動くことと、使えることは同じではない。景色は変わったけれど問いはまだ生きている、というのが2回目の出発点でした。 福原によるOpening Remarks 今回フォーカスを当てたのは、World ModelsとPhysical AIです。この1年で進展がもっとも速かった領域である一方、基盤データという観点ではギャップが大きい領域でもあります。言語モデルが数兆トークンで学習されているのに対して、ロボットの学習データは約100万軌跡。桁が大きく違います。 招待講演には、以下の4名をお迎えしました。 Iro Armeni氏（Stanford University） Amir Bar氏（Imperial College London / AMI Labs） Anastasia Varava氏（SEBx / Link） Marc Pollefeys氏（ETH Zurich / Microsoft Mixed Reality and AI Lab） とくに印象に残ったのは、Iro Armeni氏の講演でした。道路から撮影されたGoogleマップのような画像をもとに、VLMを使って住宅や建築物が何で作られているのか、どのくらいの耐久性があるのかを推定する。そうした一連の研究を紹介してくれました。建物の外壁の素材を推定するFacade Material Mappingというタスクでは8割ほどの精度が出ていて、この用途ではそれで十分に有用だということでした。基盤モデルをそのまま持ち込んだだけでは精度が届かない場面もありますが、そこに大きなコストをかけずに精度を引き上げる工夫を重ねていて、汎用のモデルをドメインの課題にどう届けるかという問いへの具体的な答えになっていました。我々が取り組んでいる製造業の分野でも、こうしたアイデアは非常に有用だと思いました。 ワークショップの前日にあたる9月8日の夜には、同じ週に開催したLIMITとの合同レセプションを、マルメ中央駅前のレストランで開きました。費用は、両ワークショップのスポンサーであるSansan、SB Intuitions、そして弊社キャディの3社で持ち、参加者は無料で参加できる形にしています。賑やかな飲み会ではなく研究者が落ち着いて議論できる場にしたかったので、座ってしっかり食事ができること、立ち上がって自由に交流できるスペースがあること、学会会場からの移動が負担にならないこと、という条件で会場を探しました。当日は、両ワークショップの招待講演者をはじめ、著名な研究者の方々に数多く参加していただきました。ワークショップのプログラムの中では時間が取れない話題までゆっくり話すことができ、運営した側としても得るものの大きい時間になりました。 ワークショップの立ち上げから当日の運営、終了後のフォローまで、実際にやったことはマニュアルの形でまとめて公開しています。プロポーザルの提出から、CFPの設計、登壇者やスポンサーへの声がけ、当日の進行、レセプションの手配まで、半年がかりのプロジェクトとして時系列で書いたものです。第1回（ICCV2025）の経験をもとにしたものですが、これから国際会議でワークショップをオーガナイズしてみようという方には参考になるかもしれません。興味のある方はこちらをご覧ください。 国際会議ワークショップのオーガナイズ・実践マニュアル（note, 2025年12月） https://note.com/gatheluck/n/ndf49c03bdb8a The Path to Manufacturing: Evolving 3D Generation to Intelligent Computer-Aided Design 本ワークショップは、生成AIを製造業に応用していく上で、3Dモデルをどこまで実際の製造に使えるものとして生成できるかを扱うワークショップです。 3D Foundation Modelによる生成技術が発展する一方で、製造用途では、見た目がそれらしいだけでは不十分で、幾何学的な正確性や、製造可能な形状であることが求められます。 そのため、製造における3Dモデリングの基盤であるCADや、CADの設計手順をプログラムとして扱うような生成AIの活用について議論されていました。 The Path to Manufacturingワークショップ 最初のKeynoteでは、Simon Fraser UniversityのHao (Richard) Zhang氏が、3D生成の発展を振り返りながら、製造までを見据えるなら、単に形状を生成するだけではなく、構造化されたCAD表現が必要になるという話がありました。特に、部品の構造だけでなく、アセンブリや機能まで考慮した表現が、Spatial AIやPhysical AI、Embodied AI、World Modelにおいて重要になるという点が印象的でした。 研究例として、建築物をプログラムとして表現するArcProなども紹介され、3Dの「形」から、より意味のある構造化表現へと進んでいく流れを感じました。ArcProでは、建築構造を独自のDSLによるプログラムとして表現し、疎な点群からそのプログラムを推定しています。 CADの設計手順をプログラムとして表現し、LLMにそのプログラムを生成させることで、CAD生成をコード生成として捉えるというアイディアは面白いと思いました。 Niloy J. Mitra氏のKeynoteでは、4D Geometryをテーマに、3Dモデルに時間や動きを加えた表現について紹介されました。ActionMeshなどの研究に加え、自然言語によるB-Rep CAD編集の研究にも触れられていました。 Xin Tong氏のKeynoteでは、3D生成を「shape」から「topology」へと発展させる方向性が紹介されました。2Dスケッチからの3D生成や、CADのB-Repの構造・トポロジーを扱う研究が取り上げられました。 Dinesh Manocha氏のKeynoteでは、見た目としては正しい3Dモデルでも、物理的には正しくないことがあるという問題が取り上げられました。そこで、従来のジオメトリや外観を再現するだけの3Dモデルを、物理的な性質やインタラクションまで扱えるモデルへ発展させ、より現実世界に近いDigital Twinを作ることを目指します。その一方で、画像だけから得られる情報には限界があり、視覚情報だけでは判断できない物理的な性質もあるという点も紹介されました。 Panelでは、LLMが研究やアイデア創出まで担うようになってきた中で、研究者は今後どのような方向に進むべきか、という学生からの質問がありました。 それに対して、以下のようなアドバイスがありました。 LLMでは扱いにくいエッジケースに取り組む 取得が難しいデータを必要とする問題に取り組み、データを蓄積する 最新の研究だけでなく、過去の論文にも目を向ける LLM時代に研究を進める上で参考になる内容で、個人的にも勉強になりました。 特に2点目は、製造現場に蓄積された図面・技術データという、キャディならではの貴重なデータ資産にもつながる話で、その強みを改めて実感できる内容でした。 本ワークショップのPaper Spotlightセッションで紹介された研究の中でも、Dacheng Qiらによる「Pointer-CAD v2」が特に印象に残りました。 初代Pointer-CADでは、B-Repの形状情報とCADのコマンド列を組み合わせ、既存の面やエッジを直接指定しながらCADモデルを生成する手法が提案されています。 今回紹介されていたPointer-CAD v2では、さらに寸法を意識したCAD生成に対応し、「Plan-Then-Construct」という構成によって、パラメータの推論と幾何形状の構築を分離しています。 また、v2では数値パラメータを離散化せず、連続値として直接予測することで、量子化による誤差を避け、寸法を正確に保ったCAD生成を目指しています。 生成したい形状だけでなく、「どの寸法で作るか」を明示的に扱える点が、製造を前提としたCAD生成という観点でも興味深いと感じました。 今回のワークショップを通して、3D生成の研究が「それらしい形を作る」だけでなく、構造・トポロジー・寸法・機能・物理特性など、現実世界のオブジェクトを構成する情報をどこまで扱えるかという方向に広がっていることを実感しました。また、全体を通して、Physical AIについてはまだ発展途上で、実世界で本当に機能するものを作るには、まだ多くの課題があるという印象を受けました。 Dinesh Manocha氏のKeynoteで「You can't cheat physics」という言葉があり、見た目として正しいものを作るだけではなく、実際に機能するものを作るには、物理的な正しさまで考える必要があるという趣旨が特に印象に残りました。 特に印象に残った発表 MolmoPoint: Better Pointing for VLMs with Grounding Tokens Christopher Clark, Yue Yang, Jae Sung Park, Zixian Ma, Jieyu Zhang, Rohun Tripathi, Mohammadreza Salehi, Sangho Lee, Taira Anderson, Winson Han, Ranjay Krishna 従来のように座標をテキストとして出力するのではなく、画像中のvisual tokenを直接選択することでpointingを行う手法です。個人的には、こうしたpointingの仕組みを使って、既存の検出タスクの一部を「検出」ではなく「pointing」として捉え直せないか、という点に興味を持ちました。 DreamCAD: Scaling Multi-modal CAD Generation using Differentiable Parametric Surfaces Mohammad Sadil Khan, Muhammad Usama, Rolandos Alexandros Potamias, Didier Stricker, Muhammad Zeshan Afzal, Jiankang Deng, Ismail Elezi CADをBezier surfaceとして表現し、CADアノテーションのない大量の3D meshを学習に利用できるようにした研究です。1.3M以上のmeshを使えるため、従来のCAD生成でボトルネックになりやすかったアノテーションに依存せずスケールさせる、という発想が面白いと感じました。 実際に著者の方ともお話ししましたが、複雑なCAD生成にはまだ課題があるとのことでした。それでも、既存の大量の3D meshという、これまで十分に活用できていなかったデータをCAD生成に取り込むという方向性は興味深かったです。 Steerable Visual Representations Jona Ruthardt, Manu Gaur, Deva Ramanan, Makarand Tapaswi, Yuki M. Asano 画像中の「どこに注目するか」を自然言語で指定できる視覚表現を提案しています。 汎用的なViTの特徴を保ちながら、対象や属性に応じて視覚表現そのものをsteerできるため、目的に応じて見たいものを指定したいタスクへの応用が期待できます。 ドメイン固有の学習データが限られる汎用Vision Modelに対しても、記号の見た目を言語で説明することで、製造業の図面などに含まれる記号の識別に活用できるのではないかと感じ、興味深い方向性だと思いました。 Make Geometry Matter for Spatial Reasoning Shihua Zhang, Qiuhong Shen, Shizun Wang, Tianbo Pan, Xinchao Wang VLMに3Dのgeometry tokenを入れるだけでは、モデルが実際には2Dの見た目に頼ってしまうという問題に着目した研究です。2D情報への依存を抑え、geometryを実際の空間推論に使わせることで、静的・動的なspatial reasoningの向上を目指しています。 Understanding Geometric Representations in Self-Supervised Vision Transformers via Subspace Intervention Weichen Zhou, Yawen Zou, Chunzhi Gu, Ran Dong, Haoran Xie, Chao Zhang 自己教師ありViTの内部にgeometryの情報がどのように表現されているのかを、linear probeの重みをSVDで分解することで調べた研究です。層によってgeometryの情報量が異なり、中間層で幾何学的な精度が高くなることなどを分析しています。 MeshFM: 2D Features Are All You Need for 3D Shape Understanding Jinfan Zhou, Richard Liu, Itai Lang, Rana Hanocka 2DのVisual Foundation Modelから得られる特徴を3D surfaceに蒸留し、3D annotationなしで汎用的な3D featureを学習する手法です。2Dで学習された表現だけでも、part segmentationやcorrespondence、deformationなどの3Dタスクに利用できる点が興味深い研究でした。 Yann LeCun氏のKeynote「World Models:Enabling the Next AI revolution」 Yann LeCun氏のKeynote「World Models:Enabling the Next AI revolution」では、LLMのスケーリングだけでは人間レベルのAIには到達せず、世界モデルやJEPAのような新しいアプローチが重要になるという主張が紹介されました。 Yann LeCun氏のKeynoteより。「研究者へのメッセージ」 このKeynoteはECCVに限らずSNSなどでも話題になっていたので、ご存じの方も多いかもしれません。最後の「If you are interested in human-level AI, don't work on LLMs」というメッセージも含め、印象に残る内容でした。 まとめ 本記事では、ECCVに参加した感想、気になった論文・発表について紹介しました。少しでもECCVの雰囲気や、現地で感じた研究の面白さが伝わっていれば嬉しいです。 今回の参加でさまざまな研究から多くの刺激を受けました。今後は研究チームとして、次の国際会議での論文発表も目指していきたいと思います。 キャディでは現在、2D・3D領域を中心にResearch Engineerを募集しています。キャディがどのような研究開発に取り組み、それを通して何を実現しようとしているのか、少しでも気になった方は、ぜひお気軽にご連絡ください。 speakerdeck.com open.talentio.com

はじめまして、わっきーです。 普段は、Copilot、Power Platform（主にはCopilot StudioやPower Automate）の活用支援、ワークショップ講師をやっているものです。 そんな私が最近、Copilot Studioを開いて思ったことがあります。

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 最後までお読みいただき、ありがとうございました！