ACCU ConferenceとC++ On Seaが一つになり、2026年6月、英国Folkestoneで初のACCU On Seaが開かれました。長く続いた2つの場が統合されたことで、C++の深い言語仕様と、より広いソフトウェア開発の議論が同じプログラムに並びます。

この変化は、単なるイベント名の更新ではありません。コードを速く生成できる時代に何を検証するのか、動いているレガシーコードをどう改善するのか、標準化途中の機能をどこまで頼ってよいのかという、実務の問いが見えてきます。

参加報告で取り上げられたセッションを軸に、いまのC++開発で持ち帰りたい3つの判断を追ってみます。

2つのカンファレンス統合でC++とソフトウェア設計が同じ場に集まった

ACCU On Seaの公式案内によると、ACCU Conferenceは1997年に始まり、C++ On Seaは2019年からC++に焦点を当ててきました。統合後もC++を中心に据えながら、他言語、テスト、ソフトウェア設計まで扱う構成です。

2026年は6月15日と16日がワークショップ、17日から20日が本編でした。プログラムは4日間・5トラックで、C++23／C++26、reflection、Contracts、安全性、非同期処理、性能、コード品質などが並びました。言語機能だけを追う場でも、一般論だけを語る場でもないと分かります。

参加報告では約400人で完売したと記され、現在の2027年スポンサー案内も2026年の参加者を400人とし、統合形式を2027年も継続すると案内しています。統合は単年の試行に終わらず、C++コミュニティと広いソフトウェア開発コミュニティをつなぐ場として続く予定です。

AI時代のボトルネックはコード生成から理解と検証へ移る

Andrei Alexandrescu氏の基調講演「The Next 20 Weeks of Systems Engineering」は、AIが大量のコードを生成しやすくする一方、検査と検証は難しいままだと問題を置きました。公式セッション紹介が示す焦点は、生成量そのものではなく、拡大するシステムの構造と振る舞いを理解できるかどうかです。

実務に引き寄せると、AIが差分を作れることと、その差分を採用できることは別です。レビュー可能な大きさか、テストで意図を固定できるか、障害時に原因を切り分けられるかが、生成速度より先に効いてきます。

Sándor Dargó氏の完全版レポートで続いて紹介されたレガシーコード近代化の講演は、この問題に具体的な形を与えています。決定的に動く静的解析と、柔軟だが非決定的なAIを組み合わせ、複雑で危険な変更ほど範囲を小さくするという考え方です。全面書き換えより、機械的に確かめられる局所的な変更へ分解する方が、AIの生産性をレビュー可能性へつなげやすくなります。

レガシーC++では内部へ触れる技法より変更範囲の局所化を先に考える

同じレポートには、変更できないコードのprivateメンバーをテストするため、テンプレートの明示的インスタンス化を利用する講演も登場します。C++ Working Draft N4950の13.9.1節には、明示的インスタンス化や明示的特殊化の宣言内にある名前には、通常のアクセス検査規則が適用されない場合があると記されています。

これはC++のルールに根拠を持つ技法ですが、privateな実装詳細への依存が消えるわけではありません。対象クラスの内部構造が変わればテスト側も壊れやすく、公開インターフェースの契約を検証するテストとは役割が異なります。

自分で変更できるコードなら、まず依存性の注入や小さな公開境界を設計できないかを考えたいところです。第三者ライブラリや移行途中のコードなど、ほかに境界を作れない場合にだけ技法を狭く閉じ込める。この順番なら、レガシーコードを止めずに改善するという前節の考え方ともつながります。

C++26 Contractsの空白をP3097がC++29へつなぐ

C++26には契約アサーションが入りますが、virtual関数にpreとpostを付けることはできません。ACCU On Seaのセッション説明は、実行時ポリモーフィズムでどの事前条件・事後条件を評価するかについて、C++26の期間内に合意へ至らなかったことを理由に挙げています。

その空白を扱うのがP3097です。P3097R3では、呼び出し式が静的に選んだ関数の条件をcaller-facing、動的ディスパッチで実際に呼ばれるfinal overriderの条件をcallee-facingとして、両方を評価するモデルを提案しています。override先へ条件を暗黙に継承するのではなく、それぞれの宣言に書かれた条件を独立に扱うのがポイントです。

概念だけを小さくすると、次のような関係です。これはP3097のモデルを示す例であり、現在のC++26でそのまま使えるコードではありません。

struct Base {
  virtual void process(int count)
    pre (count > 0);
};

struct Derived : Base {
  void process(int count) override
    pre (this->ready());

  bool ready() const;
};

Base&を通してDerived::processを呼ぶ場合、呼び出し側が見ているBaseの条件と、実際に実行されるDerivedの条件を区別して検査します。多重継承や別々に配布されるライブラリまで考えると、単に条件を継承すれば済む話ではないためです。

委員会での段階も切り分けておきたいところです。P3097R3によると、2026年6月10日にEWGはP3097R2をC++29への組み込みに向けてCWGへ送ることに合意しました。これは設計が前進したことを示しますが、C++29への最終採択や各コンパイラでの実装完了と同じ意味ではありません。

ACCU On Sea 2026から持ち帰るべきは採用判断の順番

最初の問いに戻ると、ACCU On Sea 2026が映しているのは、新機能を追うだけのC++ではありません。AIで変更を作り、変更範囲を小さく保ち、テストとレビューで意味を確かめ、標準化の段階を見誤らずに採用する。この一連の判断が同じ議論の中にあります。

日々の開発では、AIの出力を小さく検証可能な差分へ落とすことから始められます。標準化機能については、提案、Working Groupでの合意、Working Draftへの採用、コンパイラ実装を別々の段階として追うと、期待と現実を混同しにくくなります。

2つのカンファレンスが統合した意味も、ここにあります。C++の言語設計と、既存システムを安全に育てる現場の工夫を同じ場で往復できること。それが、参加できなかった開発者にも持ち帰れるACCU On Sea 2026の実践的な価値です。

出典

• Title: Trip report: ACCU On Sea 2026 -- Sandor Dargo
• URL: https://isocpp.org//blog/2026/08/trip-report-accu-on-sea-2026-sandor-dargo