2026年9月15日、CppCon 2026でBjarne Stroustrup、Guido van Rossum、Mads Torgersenによる言語設計者パネルが予定されています。司会はEmma Traceyで、C++・Python・C#という異なる設計思想を持つ3言語が同じテーブルに並びます。

気になるのは、新機能の予告だけではありません。長く使われる言語を壊さずに進化させるとき、設計者は何を守り、どこで妥協し、どの段階から利用者へ試してもらうのでしょうか。

ただし、パネルでの発言は、そのまま仕様決定になるわけではありません。3言語の現在地と「正式に決まる場所」を先に押さえ、視聴中に何を聞き分けると実務へ持ち帰れるのかを整理します。

C++26・Python 3.15・C# 15では「次の言語」の成熟度が違う

セッションは2026年9月15日10時30分から12時まで、米国山岳部夏時間（MDT）で予定されています。日本時間では翌9月16日1時30分から3時です。CppConの公式告知では、2026年のセッションは現地参加のみで、録画を後日YouTubeへ公開する予定と案内されています。

この時期、3言語はいずれも次の世代へ動いていますが、同じ「開発中」でも段階はそろっていません。

言語	2026年8月31日時点の位置	発言を聞くときの注意
C++	C++23は公開済みで、C++26は策定作業中	C++26という名前が出ても、作業中の提案と最終仕様を分ける
Python	3.15.0rc1が2026年8月4日に公開され、正式版は10月1日予定	リリース候補の挙動と、さらに先の設計案を混同しない
C#	C# 15は.NET 11で試せる最新プレビュー	公開プレビュー、未実装部分、出荷済み機能を分ける

つまり、同じパネルで未来を語っても、各発言が指す時間軸は異なります。「面白い案だ」と感じた後に、その案が構想、提案、プレビュー、確定仕様のどこにあるのかを見る必要があります。

C++・Python・C#では仕様が決まる場所が異なる

3人は言語の方向性へ大きな影響を持ちます。それでも、現在の言語仕様は個人の一言だけで決まりません。ここを押さえると、パネルを予言ではなく設計判断の解説として読めます。

C++では、問題、代替案、設計を文書へ落とし込み、フィードバックを受けて改訂した後、番号付き提案として関係する委員会で扱います。Standard C++の提案手順には、最初のアイデアから草案、反復、会議での検討へ進む流れが示されています。

Pythonでは、新しい言語機能や実装をStandards Track PEPとして記述し、公開の議論と参照実装を経て判断します。PEP 1では、最終権限をSteering Councilまたは委任されたPEP-Delegateが担い、後方互換性を壊す提案には影響と対処の説明を求めています。また、PEP 13が示すように、Guido van Rossumが2018年7月にBDFLを退いた後は、選挙で選ばれるSteering Councilを中心とする統治へ移りました。

C#では、Language Design TeamがRoslynチームと連携し、議論、提案、Language Design Meeting、必要に応じたプロトタイプを通して設計を詰めます。公式csharplangリポジトリは、活発な提案でも将来のバージョンへ入る保証はなく、実装や互換性の問題で延期・却下され得ると明記しています。

違いは意思決定者の名前だけではありません。設計の根拠をどの文書へ残すか、実装からどの段階で学ぶか、最終判断を誰が担うかが異なります。パネルでは、結論そのものに加えて、その結論へ至る判断基準を聞きたいところですね。

「壊さずに進化する」を3つの負担へ分けて聞く

パネルの紹介文は、何十年分ものコードと利用者を抱える言語を、依存する人々を壊さずにどう導くかを問いに挙げています。この問いは「互換性を守るべきか」の二択ではなく、誰がどの負担を引き受けるかという設計問題です。

聞き分けやすくするには、互換性の負担を3つへ分けます。

• 既存コードの負担：再コンパイル、書き換え、警告への対応が必要になるか
• エコシステムの負担：コンパイラ、IDE、ライブラリ、パッケージが追従できるか
• 学習の負担：新旧の書き方が並存し、どれを選ぶべきか説明できるか

たとえば、短く書ける構文を追加しても、既存の解析規則が複雑になればツールと利用者の負担が増えます。安全な既定値へ変える案も、新規コードには分かりやすくても、既存コードの意味やビルド結果を変えるなら移行経路が必要です。

そこで、各発言を「どの問題を解くのか」「移行コストを誰が払うのか」「試行段階から確定へ進む条件は何か」の3問へ置き換えます。言語が違っても、設計上のトレードオフを比較しやすくなります。

C++とPython・C#を併用する現場では境界の設計に効く

CppConはこの組み合わせを、単なる異業種交流として選んだわけではありません。公式告知では、年次C++開発者調査でPythonの併用が継続して約70%に達すること、C++とC#がWindows上で一緒に使われる場面が多いことを理由に挙げています。

C++のライブラリをPythonから呼ぶなら、所有権、エラー、データ変換を言語境界でどう見せるかがAPIの使いやすさを左右します。C++のネイティブ処理をC#アプリケーションから使う場合も、寿命管理や例外、配布単位の境界が設計に現れます。

このため、別の言語に欲しい機能の話だけでなく、「自分の言語では何を明示させ、何を処理系へ任せるのか」に注目すると実務へつながります。ライブラリやサービスのAPIを設計するときにも、便利さ、予測可能性、移行可能性のどれを優先したか説明しやすくなります。

パネルの発言を仕様決定と混同しないための追い方

視聴中は、印象的な発言を次の4種類に分けてメモすると整理しやすくなります。

1. いま解くべきだと考えている問題
2. 登壇者個人が好む設計
3. 正式なプロセスで検討中の提案
4. 実装または仕様として確定した機能

視聴後は、C++ならWG21の提案と標準化状況、PythonならPEPのStatusとPython-Version、C#ならcsharplangの提案・会議記録・実装状況へ戻ります。発言日時も一緒に残せば、後から設計が変わったときに経緯を追えます。

会場外の読者は、公開予定の録画を待つ形になります。動画URLと公開日はまだ示されていないため、CppConの公式サイトや公式チャンネルで公開状況を見ておくのが確実です。

持ち帰るべきは次の機能予想ではなく判断軸

このパネルの価値は、C++・Python・C#の次期機能を当てることではありません。異なる歴史と統治を持つ3言語が、互換性、実装可能性、学びやすさの間でどう優先順位を付けるのかを同じ問いで比べられる点にあります。

開発者が持ち帰りたいのは、「この機能が来る」という断定ではなく、「どの問題を、誰の負担で、どの検証を経て解くのか」という見方です。その判断軸があれば、後日公開される提案やリリースノートも、変更点の一覧より一段深く読めるようになります。

出典

• Title: CppCon 2026 Keynote: Language Designers Panel -- Tracey, Stroustrup, Van Rossum, and Torgersen
• URL: https://isocpp.org//blog/2026/08/cppcon-2026-keynote-language-designers-panel-tracey-stroustrup-van-rossum-a