スタンフォード大学の研究によれば、GitHub Copilotや「Facebook InCoder」などのAIプログラミング機能に依存しているプログラマーは、AIを使わないプログラマーよりも不正確でバグの多いコードを生成しやすいという結果になったそうだ（論文、GIGAZINE）。

検証は五つの課題をクリアする形でおこなわれた。与えられた共通鍵を使用して、与えられた文字列の1つは暗号化し、もう1つは復号化する2つの関数をPythonで記述するという最初の課題では、AIのサポートを受けなかったグループの79%が正しいコードを生成した一方で、AIのサポートを受けたグループは67%しか正しいコードを生成できなかったとしている。ほかの2つ目から4つ目の課題でもAIプログラミング機能を使うと脆弱性のあるコードを生成しやすいという結果となったとのこと。

三菱UFJ銀行は7日、全行アーキテクチャ戦略に関する説明会で、勘定系システムの近代化などに約750億円を投じる考えを発表した。2031年度までに勘定系システムの近代化（モダナイズ）を段階的に進める計画（日経クロステック）。

オープン基盤上に「預為フロント」を構築するなどし、開発生産性を3割向上させる。勘定元帳のデータをミラーリングする「準リアルデータベース」も整備し、取引データを活用しやすくするという。このほか、法人融資や個人ローンを中心に、融資システムも再構築する方針だとしている。

12 月の TIOBE Index で、C++ が初めて Java を上回った (The Register の記事)。

C++ は長年、Java と C の 2 強に続く 3 位をほぼキープしてきたが、近年は Python の上昇により 4 位に押し出されていた。しかし、この 2 年ほどは徐々にレーティングを伸ばしており、12 月は前年同月から 4.21 ポイント増の 11.94 %。1.70 ポイント増で 11.82 % の Java をわずかに上回って 3 位に再浮上した。

2015 年からトップを走っていた Java は 2020 年に入って急速にレーティングを落として C に抜かれ、続いて Python にも抜かれて 3 位に落ちていた。Python はその後 C を抜いて 1 位に上昇しており、12 月は前月から減少したものの 2 位 の C とは 0.1 ポイント差の 16.66 % で 1 位を守った。前年同月比ではトップ 4 いずれも増加しているが、Java だけが停滞傾向となっている。

5 位の C# は 1.48 ポイント減 (4.92 %)、6 位の Visual Basic は 1.46 ポイント減 (3.94 %) と大幅に減少した。7 位以下の増減幅は小さく、増加幅が最も大きいのは JavaScript の 0.90 ポイント増 (3.19 %、7 位)、減少幅が最も大きいのは Swift の 0.86 ポイント減 (0.91 %、15 位)。なお、2022年を代表するプログラミング言語の座はPythonとC、C++の争いになっているとのことだ。

Google は 9 日、Chrome 拡張の Manifest V2 (MV2) サポートタイムラインを更新した (MV2 サポートタイムライン、 MV3 移行タイムライン)。

Google が Chrome 拡張の信頼性向上を目指して 2018 年に発表した Manifest V3 (MV3) はコンテンツブロッカーの機能が制限されるなどとして反対の声も強く、API の実装が進んでいないことも指摘されている。当初 Google は 2023 年 6 月に MV2 サポートを完全終息する計画だったが、9 月には半年の先送りを発表していた。

9 日の更新では 2023 年 1 月に予定していた Chrome ウェブストアでの「おすすめ」バッジ表示対象変更 (MV3 限定化)、エンタープライズポリシーによる MV2 の有効化、Canary/Dev/Beta チャネルでの MV2 無効化実験開始を延期しており、2023 年 6 月の全チャネルでの MV2 無効化実験開始や 2024 年 1 月の MV2 エンタープライズポリシー終了などは「検討中」に変更された。新しいスケジュールは 2023 年 3 月までに発表する計画だという。

一方、Microsoft は 3 日に Microsoft Edge の MV3 移行タイムラインを更新し、エンタープライズポリシーによる MV2 有効化を Chromium がサポートする限り Edge でもサポートする計画を示している。Firefox や Brave、Vivaldi などは MV3 に対応する一方で MV2 を必要とするコンテンツブロッカー等のサポートを継続する意向を示しているが、Microsoft はおおむね Google に歩調を合わせているようだ。

headless 曰く、

Google のマテリアルデザインチームが 24 時間表示の時計のためのタイムピッカーデザインで直面した困難について解説している (Material Design Blog の記事、 9to5Google の記事、 Android Poice の記事)。

2020 年 10 月、最初にリリースしたマテリアルデザインの 24 時間タイムピッカーは 2 重リングになっており、外周で 1 ～ 12 時、内周で 13 ～ 24 時を選択する仕組みだったという。しかし、内周での選択が難しいといった懸念を受けて 1 重リングで 1 ～ 24 時までを選択するデザインに変更。このデザインでは偶数の時間のみ表示され、奇数の時間はスペースで表現されていた。このリングは時間の選択時のみで、分の選択時には表示が切り替わる仕組みだ。

しかし、このデザインは重要なアクセシビリティの問題を解決する一方で、ユーザーが認知しているアナログ時計の文字盤と一致せず、奇数の時間を選択するのにスペースを選択するというのが明確でないなどの問題があった。チームは 50 以上の異なるプロトタイプデザインを作るなど試行錯誤したが、24 時間表示のアナログ時計がユーザーの混乱を招くことに変わりなかったようだ。

最終的に 24 時間のタイムピッカーはデジタル方式が確実という結論に達し、オプションで 2 重リングのアナログ方式タイムピッカーも選択できるようにする計画とのことだ。スラドの皆さんはわかりやすく、かつ使いやすい24時間のアナログ方式タイムピッカーのアイディアがあるだろうか。

あるAnonymous Coward 曰く、

複雑な問いかけにも回答するチャットAI「ChatGPT」がテスト公開され注目が集まっているが、プログラミングの質問・回答サイト「Stack Overflow」は6日、早くもこのChatGPTを使った回答を禁止する方針を発表した（Stack Overflowの発表、ITmedia、GIGAZINE、ZDNet Japan）。

ChatGPTは正しい回答もするが、開発元のOpenAIも認めているように「もっともらしく聞こえるが、不正確な回答や意味不明な回答」をすることも多々あるという。Stack Overflowでは「一番の問題は、ChatGPTが生成する回答は不正確である確率も高いのに、適切であるように思われることが多く、回答が非常に容易に生成されることだ」といった議論の末、サイトとユーザーにとって「おおむね有害」であると結論。ChatGPTを使用した投稿を一律禁止することを決定したとのこと。

あるAnonymous Coward 曰く、

GitHub日本法人の記事によるとヤマト運輸のDX推進を担当する中林紀彦執行役員曰わく、「これまでの内製化はアウトソーシングからの見直しが主体でした。これからは、アーキテクチャのデザインや、GitHubを活用したソースコードのガバナンス・標準化が実行可能なメンバーによるコアな開発は内製化し、ソースコードを書くなど単純な作業は外部に委託するなど柔軟な対応が必要です」らしい（ITmedia）。

後日、記事は修正され、「これまでの内製化はアウトソーシングからの見直しが主体でした。今後は、アーキテクチャのデザインやGitHubを活用したソースコードのガバナンス・標準化が実行可能なメンバーによるコアな開発は内製化しつつ、短期的にリソースが足りない部分は外部に委託するなど柔軟な対応が必要になります」と書き換えられた。

通常このような記事は録音を元に書き起こされるものであるが、本当はどのような発言があったのだろうか。

イーロン・マスク氏がTwitterの買収後、同社内の各部門に対してさまざまなリストラを進めてきた。同氏は全従業員に対して自身のビジョンを説明、Twitterに残るかどうか判断するよう求めていた。しかし、この残る決断をした中からさらに50人ほど解雇されていると報じられている。

あるAnonymous Coward 曰く、

Twitterでハードワークに耐えることを誓約したうちの50人が、「コードが満足のいく出来ではない」という理由で解雇された。
これらの50人はハードワークを拒否してTwitterを去った人たちより、退職時にもらえる額が8週間分少なくなる。
ハードワークを拒否した人たちは12週間分の給料分が支払われるのに対し、今回解雇された人たちは4週間分となるからである。
こんなことなら、さっさと辞めておけばよかったと思っているだろう（GIGAZINE）。

Microsoft は 11 月 23 日、Outlook REST API v2.0 および Beta エンドポイントの廃止を延期すると発表した (Exchange Team Blog の記事、 Neowin の記事)。

Outlook REST API は Outlook.com や Office 365 などのメールボックスデータにアクセスする API。Microsoft は幅広いサービスに対応可能な Microsoft Graph への移行を進めており、2022 年 11 月 30 日に Outlook REST API を廃止すると 2 年前に発表していた。

しかし、顧客やパートナーからのフィードバックを受けて、廃止の延期を決めたという。現時点で新しい廃止時期は決まっていないが、Microsoftでは 2023 年中の廃止を目指しており、エンドポイントをブロックする前に 6 か月の猶予期間を設けるとのことだ。

headless 曰く、

やや旧聞となるが、Microsoft が先週 Dev チャネルでリリースした Windows 11 Insider Preview ビルド 25247 には 2 種類のフランス語キーボードレイアウト (AZERTY と BÉPO) が追加されている (Windows Insider Blog の記事、 Softpedia の記事)。

AZERTY はフランス語キーボードの標準的配列であり、以前から Windows でフランス語の既定の配列になっている。今回追加された AZERTY キーボードでは記号の配置が変更されており、フランス語で必要なすべての文字を入力できるように設計されているという。特に言及はないがフランス規格協会 (AFNOR) による AZERTY 配列のようだ。

新しい AZERTY 配列を使うには、設定>時刻と言語>言語と地域から言語のオプションを開き、キーボードの追加で「フランス語 (標準、AZERTY)」を選択すればいい。フランス語に限らず、英語などのラテン文字を使用する言語で利用可能だ。従来の AZERTY 配列は「フランス語 (レガシ、AZERTY)」という名称に変更されており、引き続き既定のフランス語キーボードとして使われる。

BÉPO はコミュニティが開発し、AFNOR が標準化したもので、アルファベット上段がBÉPOという並びになっている。フランス語以外でもラテン文字を使用する言語でエルゴノミックかつ高効率なキーボード配列として利用できるほか、プログラミングにも適しているという。こちらはキーボードの追加で「フランス語 (標準、BÉPO)」を選択すれば追加できる。

プログラミングに適しているといっても、あまり使いそうもない記号が優先されていたり、日本語環境では使い慣れない AltGr (右 Alt) との組み合わせで入力する記号があったりと、フランス語のように綴字記号を多用する言語を入力するのでなければ使いやすくはなさそうだ。スラドの皆さんのご意見はいかがだろうか。

GitHubが、2022年に同プラットフォーム上で使用されたプログラミング言語に関する統計データを発表した（GitHub、GIGAZINE、Publickey）。プログラミング言語トップ10は以下の通り。

1. :JavaScript
2. :Python
3. :Java
4. :TypeScript
5. :C#
6. :C++
7. :PHP
8. :シェルスクリプト
9. :C言語
10. :Ruby

なお2022年に最も使用されたプログラミング言語は「JavaScript」で、最も伸びたプログラミング言語は「HCL(HashiCorp Configuration Language)」、使用率が減少したプログラミング言語は「PHP」だったとしている。HCLが増えているのはープンソースのソフトウェアツールであるTerraformとIaCプラクティスの人気が高まりが一因であるらしい。なお、前年比での使用率が最も増加したプログラミング言語は次の通りとなっている。

1. :HCL(成長率56.1％)
2. :Rust(成長率50.5％)
3. :TypeScript(成長率37.8％)
4. :Lua(成長率34.2％)
5. :Go(成長率28.3％)
6. :シェルスクリプト(成長率27.7％)
7. :Makefile(成長率23.7％)
8. :C言語(成長率23.5％)
9. :Kotlin(成長率22.9％)
10. :Python(成長率22.5％)

西 和彦氏は17日、MSX2のオリジナル公式エミュレータ「MSX 0」を発表した。公開されたエミュレータは、「MSX 0 stack」と名付けられている。すでに市販されている小型マイコンモジュール「M5Stack」上でMSX-BASICが動いている模様。今後はI/Oを制御する「MSX 0 IOT BASIC」の実装をおこなうだけでなく、M5Stack以外のプラットフォームへの移植も考えているとのこと。同氏は現在「MSX 3」の開発を進めているが、こうしたハードウェアだけでなく、ソフトウェア面からもMSXの可能性を広げる考えである模様（西 和彦氏のツイート、4Gamer）。

Mozilla は 17 日、addons.mozilla.org で 11 月 21 日から Manifest V3 (MV3) 拡張機能の受付を開始し、Firefox Nightly でテストできるよう署名すると発表した (Mozilla Add-ons Community Blog の記事、 The Register の記事)。

MV3 拡張機能は来年 1 月 17 日リリースの Firefox 109 で一般に利用可能となり、以降のリリースで段階的に MV3 サポート機能を追加していくが、Firefox は MV2 拡張機能サポートを当面継続する。Mozilla では MV2 から MV3 へのシームレスな移行を目指しており、2023 年末に向けて MV3 のロールアウトを評価して MV2 廃止スケジュールを決めるとのこと。

Firefox の MV3 ではシンプルで統合された API や強化されたセキュリティとプライバシーのメカニズム、よりよいモバイルプラットフォームサポート機能を提供する。Mozilla は他のブラウザーベンダーや開発者コミュニティと協力してブラウザー間の互換性維持に努めるが、以下の 2 点については他社と異なるアプローチになるという。

1. MV3 では Web Request API が非推奨となり、Declarative Net Request (DNR) がブロッキング用に追加される。Firefox の MV3 では互換性のため DNR をサポートするとともに、より柔軟でクリエイティブな処理が可能な Web Request のサポートも継続
2. MV3 ではバックグラウンドスクリプト実行にサービスワーカーを使用するが、Firefox の MV3 では Event Pages の使用を継続する。将来的にはサービスワーカーサポートも追加する計画

headless 曰く、

米企業のふりをしたロシア企業 Pushwoosh のユーザープロファイリングコードを数千本のスマートフォンアプリ (Android / iOS) が使用しており、米陸軍の iOS アプリでも 3 月まで使われていたそうだ (Reuters の記事、 The Register の記事、 9to5Mac の記事)。

同社はロシアでデータ処理も行うソフトウェア企業として登録されており、シベリア・ノボシビルスクに本社があるという。同社の設立者 Max Konev 氏は 9 月に Reuters のインタビューに答え、ロシア人であることを隠したことはないと述べているが、ソーシャルメディアや米国での登録情報によると、カリフォルニアやメリーランド、首都ワシントンなどを本拠とする米企業になっているとのこと。

Konev 氏はロシア政府とのつながりはなく、データは米国やドイツに保存しているとも述べており、Reuters は同社によるユーザーデータ不正使用の形跡を見つけられなかったそうだが、ロシア当局からデータの強制提出を命じられる可能性は否定できない。そのため、米陸軍による使用は国家安全保障上のリスクも懸念される。

陸軍は Reuters に対し、問題のアプリがナショナルトレーニングセンター (NTC) で使われていたが、3 月にセキュリティ上の懸念から削除したと述べたという。The Register に対しては、問題のアプリが 2016 年に開発されたもので、無料版の Pushwoosh を使用していたと説明している。また、現在では2016 年当時と比べて規定が厳格化しており、有料版のソフトウェアが利用可能な場合は無料版の使用が禁じられているとのことだ。

米国家安全保障局 (NSA) は 10 日、メモリ安全性の問題に対応するためのガイダンスを公開し、可能な限りメモリ安全なプログラミング言語を使用するよう推奨した (プレスリリース、 The Register の記事、 ガイダンス: PDF)。

Microsoft は 2019 年、過去 12 年間の Microsoft 製品の脆弱性は 70 % がメモリ安全性に起因すると述べており、Google も 2020 年に Chromium の重大な脆弱性の 70 % がメモリ安全性に起因すると述べていた。

広く使われているCやC++などの言語はメモリ管理の自由度が高い一方で、必要なメモリ参照の確認はプログラマーに強く依存する。ソフトウェア解析ツールを使用すればある程度の保護は可能になるが、メモリ安全な言語はそれ自体がメモリ管理の問題の多くに対応可能な保護機能を提供する。そのため、可能な場面ではメモリ安全な言語の使用が推奨されるとのこと。メモリ安全な言語の例としては、C#・Go・Java・Ruby・Rust・Swift が挙げられている。