macos | TECH NOTE

Xcode 26ベータに生成AIが統合 ― Claude Sonnet 4対応で広がる開発支援の可能性

ここ数年、生成AIを開発に取り入れる動きは急速に広がり、VS Code や Cursor といったエディタ・IDEにおける統合が先行してきました。これらの環境ではコード補完やリファクタリング、バグ修正の提案などが自然言語ベースで可能となり、多くの開発者が日常的に利用するようになっています。一方で、Appleの公式IDEである Xcode はこれまで生成AI統合においてやや遅れを取っていました。

その状況を変えるのが現在提供中の Xcode 26ベータ です。このバージョンでは「Intelligence」と呼ばれる新しい支援機能が追加され、自然言語によるコード提案やドキュメント生成が試験的に利用できるようになっています。さらに注目すべきは、従来のChatGPTに加え、AnthropicのClaude Sonnet 4 を利用できるようになった点です。これにより、Appleプラットフォームの開発者は複数のモデルを比較しながら、自身のプロジェクトに最も適したAI支援を取り込むことが可能となります。

もちろん現時点ではベータ版であり、仕様は今後の正式リリースに向けて変更される可能性があります。しかし、Apple公式の開発環境に生成AIが組み込まれること自体が大きな転換点であり、アプリ開発者にとっては生産性と創造性を高める追い風になると期待されます。本記事では、このXcode 26ベータで確認されている主要な新機能と改善点を整理し、開発者にとっての意味合いを考察します。

主な新機能や強化点

生成インテリジェンスツール（Intelligence）

Xcode 26 ベータ最大の目玉は、IDE内で自然言語によるコード支援を行える「Intelligence」機能です。従来は外部エディタに頼るしかなかった生成AIのコーディング支援を、Xcodeそのものに統合することで、アプリ開発の文脈を理解したより精度の高い提案が可能になります。コード補完、リファクタリング、コメントやドキュメント生成、テストコード自動生成といった機能が試験的に利用可能であり、Appleエコシステムに特化した開発ワークフローの効率化が期待されます。

Claude Sonnet 4 のサポート

今回のベータでは、標準の ChatGPT に加え、Anthropic Claude Sonnet 4 が利用できるようになりました。これにより、開発者はAIモデルを切り替えながら比較検証でき、生成品質や応答速度などプロジェクトの性質に応じた最適な選択が可能となります。今後はさらに他のモデルやローカルモデルの選択肢も拡大する見込みで、AI活用の自由度が増す点は大きな進歩です。

Foundation Models フレームワーク

WWDC 2025で発表された Foundation Models フレームワーク がXcode 26にも統合され、アプリにオンデバイスAIを直接組み込むための仕組みがベータ段階で利用できます。これにより、ユーザーのデバイス上でモデルを動作させ、プライバシーを守りながらオフライン環境でもAI機能を提供できる設計が可能となります。開発者はクラウド依存を減らし、ユーザー体験の質を高められるようになります。

開発体験の高速化と効率化

Xcode 26 ベータではパフォーマンス改善も進んでいます。インストーラのダウンロードサイズは約24%削減され、プロジェクトの読み込み時間が最大40%短縮。さらに、大規模なSwiftファイルでのテキスト編集が最大50%高速化されています。AI支援だけでなく、IDEそのものの基盤が強化されたことで、日常的な編集作業やビルド作業におけるストレスが軽減されます。

UIと操作性の刷新

開発者体験を高めるために、ナビゲーションやUIも改善されています。タブビューが再設計され、複数ファイルやツールを横断的に扱いやすくなりました。また、Voice Controlを使ってSwiftコードを音声で入力できるようになり、アクセシビリティや多様な作業スタイルへの対応が進んでいます。加えて、ローカリゼーション機能も改善されており、多言語対応アプリの開発をより効率的に進められる環境が整っています。

Apple開発環境との統合強化

生成AI機能はXcode単体の改良にとどまらず、Appleの開発ツール全体の強化と連動しています。TestFlightやApp Store Connectとの統合ワークフローにおいても、将来的には生成AIによるリリースノート自動生成やテストカバレッジ改善が期待されており、Appleエコシステム全体での開発体験を底上げする布石となっています。

このように、Xcode 26 ベータは単なるAI支援機能の追加にとどまらず、IDE基盤の高速化・UI刷新・オンデバイスAI対応・Claude Sonnet 4サポート といった幅広い改善を含んでいます。

開発者にとっての利点

IDE内で完結する生成AIワークフロー

最大の利点は、生成AIを利用するためにVS CodeやCursorといった外部エディタに切り替える必要がなくなり、Xcode単体で自然言語によるコード支援が利用できる点です。従来のAppleプラットフォーム開発では、プロジェクト構造やビルド設定の特殊性から外部ツールとXcodeを併用する必要がありましたが、Intelligence機能の搭載によってその断絶が解消されます。コード補完・リファクタリング・ドキュメント生成などをすべてIDE内で行えるため、開発の流れを途切れさせずに作業できるのは大きな効率化です。

Claude Sonnet 4による選択肢の拡大

Xcode 26ベータで Claude Sonnet 4 がサポートされたことも重要です。これにより、開発者は標準のChatGPTだけでなく、Claudeを含む複数のモデルを状況に応じて使い分けられます。Claudeは自然言語理解や要約に強みを持ち、ドキュメント生成や既存コードのリファクタリング提案といったシナリオで特に有効です。一方でChatGPTや将来的なローカルモデルはコード生成や補完精度で強みを発揮するため、開発内容やチームのワークフローに合わせて最適なAIを選べる柔軟性が提供されます。

学習コストの低減と生産性向上

Intelligence機能は自然言語ベースで動作するため、チーム内で経験が浅い開発者でも学習コストを抑えて効率的に開発へ参加できます。たとえば「このメソッドを非同期対応に書き直して」と指示すればAIが提案を返すため、経験不足を補完しつつ開発スピードを維持できます。また、Claude Sonnet 4のような高性能モデルを組み合わせることで、レビュー前の一次修正やコメント補完といった雑務を自動化し、熟練エンジニアはより高度な設計や最適化に集中できる環境が整います。

Appleエコシステムとの親和性

Xcodeに直接統合されたAI支援は、AppleのSDKやフレームワークに対する知識を前提とした提案が可能になるポテンシャルを持っています。SwiftUIやCore Data、Combineなど、Apple固有の技術スタックに沿ったコード改善を即座に提案できることは、汎用的なエディタでは得にくい強みです。さらに、Foundation Modelsフレームワークとの組み合わせによって、オンデバイスで動作するAIをアプリに組み込みながら、その開発支援もXcodeで完結させられる未来が見えてきます。

このように、Xcode 26ベータにおける Intelligence機能 と Claude Sonnet 4サポート は、開発効率の向上にとどまらず、モデル選択の柔軟性・学習コスト削減・Apple固有技術との親和性 といった多面的な利点を開発者にもたらします。正式版での安定化が進めば、XcodeはAppleプラットフォーム開発における生成AI活用の中心的な環境となるでしょう。

おわりに

Xcode 26 ベータにおける生成AI統合は、まだ試験段階ではあるものの、開発者にとって大きな意味を持つ一歩といえます。これまで VS Code や Cursor を中心に広がってきたAI支援が、Apple公式のIDEに組み込まれたことで、プラットフォーム特有の制約や作業の断絶が解消されつつあります。日常的にXcodeを利用する開発者にとって、環境を切り替えることなくAIによる補助を受けられるのは大きな利点です。

特に注目すべきは、Intelligence機能 の導入と Claude Sonnet 4対応 です。Intelligenceは自然言語でコードを扱える仕組みを提供し、ドキュメント生成やリファクタリング支援など、これまで時間を取られていた作業を効率化します。また、Claude Sonnet 4が利用可能になったことで、ChatGPTと比較しながらシナリオに応じたAIを選択できる柔軟性が生まれました。これにより、開発者は自分のワークフローやチームの開発スタイルに合った最適なモデルを活用できるようになります。

もちろん、ベータ版である以上、今後のアップデートによって仕様変更や機能強化が行われる可能性は高いです。提案精度や安定性がどこまで向上するか、正式版に向けて注視する必要があります。ただし、現時点で試すことには十分な価値があり、自身のプロジェクトやチーム開発にどのように活かせるかを早めに検証しておくことは有益でしょう。

生成AIは補助的な立場から、次第に開発工程の重要な役割を担う存在へと変わりつつあります。Xcode 26 ベータはその流れをApple公式環境にもたらす第一歩であり、今後の開発スタイルに少なからず影響を与えると考えられます。正式リリースが近づくにつれ、Xcodeが「AIと共に開発を進めるプラットフォーム」としてさらに進化していく姿に期待が集まります。

参考文献

Xcode 26 Release Notes（Apple Developer）
https://developer.apple.com/documentation/xcode-release-notes/xcode-26-release-notes
What’s new in Xcode 26（Apple Developer）
https://developer.apple.com/xcode/whats-new/
Apple supercharges its tools and technologies for developers（Apple Newsroom, 2025年6月）
https://www.apple.com/newsroom/2025/06/apple-supercharges-its-tools-and-technologies-for-developers/
Here is everything Apple announced at its annual developer conference（Reuters, 2025年6月）
https://www.reuters.com/business/here-is-everything-apple-announced-its-annual-developer-conference-2025-06-09/
Xcode 26: Everything iOS Developers Need to Know from WWDC 2025（Medium, Aeturnum Inc.）
https://medium.com/aeturnuminc/xcode-26-everything-ios-developers-need-to-know-from-wwdc-2025-f92e3edfb07b
Apple is building an AI coding tool for Xcode with Anthropic Claude integration（The Verge, 2025年6月）
https://www.theverge.com/news/660533/apple-anthropic-ai-coding-tool-xcode

イーロン・マスクのxAI、AppleとOpenAIを独禁法違反で提訴

2025年8月25日、イーロン・マスク氏が率いるAIスタートアップ「xAI」が、AppleとOpenAIをアメリカ連邦裁判所に提訴しました。今回の訴訟は、単なる企業間の争いという枠を超え、AI時代のプラットフォーム支配をめぐる大きな論点を世に問うものとなっています。

背景には、Appleが2024年に発表した「Apple Intelligence」があります。これはiPhoneやMacなどAppleのエコシステム全体にAIを深く組み込む戦略であり、その中核としてOpenAIのChatGPTが標準で統合されました。ユーザーはSiriを通じてChatGPTの機能を自然に利用できるようになり、文章生成や要約といった高度な処理を日常的に行えるようになっています。これはユーザー体験の向上という意味では歓迎される一方、競合他社にとっては「Appleが特定企業のAIを優遇しているのではないか」という懸念にもつながりました。

xAIは、自社の生成AI「Grok」が排除されていると主張し、AppleとOpenAIが結んだ提携が競争を阻害していると訴えています。マスク氏自身、OpenAIの創設メンバーでありながら方向性の違いから離脱した経緯を持ち、かねてからOpenAIに対して強い批判を行ってきました。今回の提訴は、その因縁が司法の場に持ち込まれた形ともいえます。

本記事では、この訴訟に至る経緯と主張の内容を整理しつつ、今後の展望について考察します。Apple、OpenAI、そしてxAIの動きがAI市場全体に与える影響を理解するためにも、今回の事例は注視すべき重要な出来事です。

Apple IntelligenceとChatGPTの統合

Appleは2024年6月のWWDCで「Apple Intelligence」を発表しました。これはiOS、iPadOS、macOSといったApple製品のOS全体に組み込まれる新しいAI基盤であり、従来のSiriや検索機能にとどまらず、ユーザーの作業や生活を幅広くサポートすることを目指しています。Apple自身が開発したオンデバイスAIに加えて、外部モデルを補助的に活用できる点が大きな特徴です。

その中心に据えられたのがOpenAIのChatGPTの統合です。Apple Intelligenceは、ユーザーがSiriに質問したり、メールやメモ、Safariなどの標準アプリで文章を入力したりする際に、その内容に応じて「これはChatGPTに任せる方が適している」と判断できます。たとえば旅行プランの提案、長文記事の要約、メール文面の丁寧なリライトなど、従来のSiri単体では対応が難しかった生成的タスクがChatGPT経由で処理されるようになりました。これにより、ユーザーはアプリを切り替えることなく高度な生成AI機能を自然に利用できるようになっています。

また、この統合はテキストにとどまりません。画像やドキュメント、PDFなどを共有メニューから直接ChatGPTに渡し、要約や説明を得ることも可能です。これにより、ビジネス用途から日常的な作業まで、幅広い場面でChatGPTを活用できる環境が整備されました。

さらにAppleは、この仕組みにおいてプライバシー保護を強調しています。ユーザーが同意しない限り、入力した内容はOpenAI側に保存されず、Appleが中継する形で匿名利用が可能です。加えて、ユーザーがChatGPT Plusの有料アカウントを持っている場合には、自分のアカウントでログインして最新モデル（GPT-4.0以降）を利用することもできるため、柔軟性と安心感を両立しています。

Appleにとって、この統合は単に便利な機能を追加するだけでなく、「ユーザーが信頼できる形でAIを日常に取り入れる」ことを体現する戦略の一部といえます。しかし同時に、この優遇的な統合が競合他社の機会を奪うのではないかという懸念を呼び、今回の訴訟の背景ともなっています。

xAIの主張と訴訟の争点

xAIは、AppleとOpenAIの提携がAI市場における健全な競争を阻害していると強く主張しています。訴状で掲げられている論点は複数にわたりますが、大きく分けると以下の4点に集約されます。

1. プラットフォーム支配の濫用

Appleは世界的に圧倒的なシェアを持つiPhoneというプラットフォームを通じて、ChatGPTを唯一の外部生成AIとしてシステムに統合しました。これにより、ユーザーが意識しなくてもChatGPTが標準的に呼び出される設計となり、xAIが提供する「Grok」などの競合サービスは不利な立場に置かれています。xAIは「Appleは自社のプラットフォーム支配力を利用し、OpenAIに特別な優遇を与えている」と主張しています。

2. データアクセスの独占

ChatGPTがOSレベルで統合されたことにより、OpenAIは膨大なユーザーのやり取りやクエリに触れる機会を得ました。これらのデータはモデル改善や学習に活用できる潜在的価値を持ち、結果的にOpenAIがさらに競争上の優位を拡大することにつながるとxAIは指摘しています。AIモデルはデータ量と多様性が性能向上の鍵を握るため、この「データの独占」が競合他社にとって致命的なハンディキャップになるという懸念です。

3. App Storeでの不平等な扱い

xAIは、Appleが提供するアプリストアの運営にも問題があると訴えています。たとえば、ChatGPTは「必携アプリ」や「おすすめ」カテゴリーで目立つ場所に表示される一方、Grokなどの競合は同等の扱いを受けていないとされています。ランキング操作や露出の偏りといった手法で、ユーザーが自然に選ぶ選択肢から競合を排除しているのではないか、という疑念が投げかけられています。

4. OpenAIとの因縁と市場支配批判

マスク氏は2015年にOpenAIを共同設立したものの、2018年に営利化の方向性に反発して離脱しました。それ以降、OpenAIの企業姿勢に批判的であり、営利優先の姿勢が公益性を損なっていると繰り返し主張してきました。今回の訴訟も、その延長線上にあると見る向きが強く、単なるビジネス上の争いにとどまらず、「AI市場全体の透明性と公平性」を問いかける政治的・社会的なメッセージも含まれていると考えられます。

訴訟の核心にある問題

これらの主張を整理すると、訴訟の本質は「Appleがプラットフォームを利用して特定企業（OpenAI）に過度な優遇を与えているかどうか」という一点にあります。もし裁判所が「AI市場は独立した市場であり、Appleがその入り口を握っている」と判断すれば、独占禁止法の観点から厳しい追及が行われる可能性があります。逆に「これはあくまでiPhoneの一機能であり、他社もアプリとして参入可能」と認定されれば、AppleとOpenAIの提携は正当化される可能性が高まります。

このように、xAIの主張は技術的・経済的な側面だけでなく、Musk氏個人の因縁や思想的背景も絡んでおり、単純な企業間の争い以上の重みを持っています。

他社との比較とAppleの立場

AppleとOpenAIの提携が注目される一方で、他の大手AI企業との関係も整理する必要があります。実際にはAppleがChatGPTだけを特別に扱っているわけではなく、他のモデルも候補に挙がっており、事情はより複雑です。

まずAnthropicのClaudeについてです。Claudeは「安全性と透明性を最優先する」という設計思想を掲げており、倫理的フィルタリングやリスク低減の仕組みに力を入れています。そのため、過激な表現や偏った回答を出しにくく、Appleが重視する「安心・安全なユーザー体験」と相性が良いと見られています。報道ベースでも、Claudeは将来的にAppleのエコシステムに統合される有力候補として取り沙汰されています。

次にGoogleのGeminiです。Googleは検索やAndroidでのAI統合を進めており、Appleともクラウドや検索契約の関係があります。Geminiは既に「Siriとの連携を視野に入れている」とされており、今後はChatGPTに次ぐ統合先になると予想されています。これはAppleがOpenAIだけに依存するリスクを避け、複数のパートナーを持つことで交渉力を確保する戦略の一環と考えられます。

一方で、イーロン・マスク氏のGrokについては状況が異なります。GrokはX（旧Twitter）との強い連携を前提にしたサービスであり、Musk氏の思想やユーモアが色濃く反映される設計になっています。これが魅力でもあるのですが、Appleのように「ブランド価値＝中立性・安心感」を最優先する企業にとっては大きなリスク要因です。もし偏った発言や政治的にセンシティブな応答が出た場合、それが「Apple公式の体験」として受け取られる可能性があるからです。結果として、AppleがGrokを採用するハードルは非常に高いと考えられます。

こうした比較から見えてくるのは、Appleの立場が「技術力や話題性」だけでなく、「自社ブランドと安全性にどれだけ適合するか」を基準に提携先を選んでいるということです。ChatGPTの統合はその第一歩にすぎず、今後はClaudeやGeminiが加わることで複数のAIを使い分けられる環境が整っていく可能性があります。逆に言えば、この「Appleが選んだパートナーしかOSレベルに統合されない」という点が、競争排除の疑念につながり、今回の訴訟の争点のひとつとなっています。

今後の展望

今回の訴訟がどのように展開するかは、単なる企業間の争いにとどまらず、AI業界全体のルール形成に影響を及ぼす可能性があります。注目すべきポイントはいくつかあります。

1. 法廷での市場定義の行方

最も大きな論点は「AIチャットボット市場」が独立した市場と認められるかどうかです。もし裁判所が「AIアシスタントはスマートフォン市場の一機能に過ぎない」と判断すれば、AppleがOpenAIを優先的に統合しても独占禁止法違反には当たりにくいでしょう。しかし「生成AI市場」や「AIチャットボット市場」が独立したものと見なされれば、AppleがOSレベルのゲートキーパーとして特定企業を優遇している構図が強調され、xAIの主張に追い風となります。

2. Appleの今後の開放性

現時点ではChatGPTだけが深く統合されていますが、今後AppleがClaudeやGeminiといった他のモデルを正式に組み込む可能性があります。もし複数のAIをユーザーが自由に選択できるようになれば、「AppleはOpenAIを特別扱いしている」という批判は和らぐはずです。一方で、Appleが統合パートナーを限定的にしか認めない場合には、再び独占的な優遇措置として問題視される可能性があります。

3. xAIとGrokの立ち位置

今回の訴訟は、xAIの「Grok」をAppleのエコシステムに組み込みたいという直接的な意図を持っているわけではないかもしれません。しかし訴訟を通じて「公平性」の議論を表舞台に引き出すことで、将来的にAppleが他社AIを広く受け入れるよう圧力をかける狙いがあると見られます。もしAppleがより開放的な統合方針を打ち出すなら、Grokも選択肢のひとつとして検討される余地が生まれるでしょう。

4. 世論と規制当局の動向

この訴訟の影響は裁判所だけにとどまりません。AI市場における透明性や競争環境の確保は、各国の規制当局やユーザーの関心事でもあります。特にEUや米国の競争当局は、GAFAの市場支配力に敏感であり、AI分野においても調査や規制が強化される可能性があります。今回の訴訟は、そうした規制強化の口火を切る事例になるかもしれません。

5. 業界全体への波及効果

Apple、OpenAI、xAIの三者の動きは、AI業界全体に大きな波紋を広げます。もしAppleが複数モデルを統合する方向に進めば、ユーザーはスマートフォンから複数のAIをシームレスに利用できる未来が近づきます。逆に統合が限定的なままなら、ユーザーの選択肢が制限され、アプリ単位での利用にとどまる状況が続くかもしれません。

まとめ

要するに、今後の展開は「法廷での市場の捉え方」と「Appleがどこまで開放的にAIを受け入れるか」に大きく左右されます。訴訟そのものは長期化が予想されますが、その過程でAppleや規制当局がAIの競争環境にどう向き合うかが明らかになっていくでしょう。結果として、ユーザーがAIをどのように選び、どのように利用できるかという自由度が大きく変わる可能性があります。

まとめ

今回の訴訟は、表面的にはイーロン・マスク氏率いるxAIとApple、OpenAIとの間の対立に見えますが、その本質は「AI時代におけるプラットフォーム支配と競争のあり方」を問うものです。AppleがChatGPTをOSレベルで深く統合したことは、ユーザーにとっては利便性の大幅な向上を意味します。Siriが一段と賢くなり、文章生成や要約といった高度な機能を標準で利用できるようになったのは歓迎される変化でしょう。

しかし同時に、この優遇的な扱いが他のAIサービスにとって参入障壁となり得ることも事実です。特にGrokのようにAppleのブランド戦略と相性が悪いサービスは、実力を発揮する前に市場から排除されてしまう懸念があります。ここには「ユーザーの体験を守るための選別」と「競争環境を不当に制限する排除」の境界線という難しい問題が存在しています。

また、この訴訟はAI市場のデータ独占問題にも光を当てています。ChatGPTのようにOSに深く統合されたサービスは、ユーザーのやり取りを通じて膨大なデータを得る可能性があります。それがモデル改善に直結する以上、データを握る企業がさらに強者になる「勝者総取り」の構図が加速しかねません。公平な競争を保つために規制や透明性が求められるのは当然の流れといえるでしょう。

一方で、AppleはOpenAI以外のAIとも提携を検討しており、ClaudeやGeminiのようなモデルが今後SiriやApple Intelligenceに追加される可能性があります。もしAppleが複数モデルをユーザーに選ばせる方向へ進めば、今回の訴訟が指摘する「排除」の問題は緩和され、むしろユーザーの選択肢が広がるきっかけになるかもしれません。

結局のところ、この訴訟は単なる企業間の駆け引きにとどまらず、AIの利用環境がどのように形作られていくのかという社会的な課題を突きつけています。ユーザーの自由度、企業間の競争の公正性、規制当局の役割。これらすべてが絡み合い、今後のAI市場の姿を決定づける要因となるでしょう。

今回のxAIの提訴は、結果がどうであれ「AI時代の競争ルール作りの第一歩」として記録される可能性が高いといえます。

参考文献

Musk’s xAI sues Apple and OpenAI over ChatGPT and iPhone integration
https://www.ft.com/content/f4f8e341-0b28-4b53-85e6-3961ade0c881
Elon Musk’s xAI is suing OpenAI and Apple
https://www.theverge.com/news/765171/elon-musk-apple-openai-antitrust-lawsuit
Elon Musk’s xAI sues Apple and OpenAI in expanding fight over competition
https://www.washingtonpost.com/technology/2025/08/25/elon-musk-xai-lawsuit-apple-openai/
Elon Musk’s xAI sues Apple, OpenAI over AI competition, App Store rankings
https://www.reuters.com/legal/litigation/elon-musks-xai-sues-apple-openai-over-ai-competition-app-store-rankings-2025-08-25/
Musk denuncia a Apple y OpenAI por impedir la competencia en inteligencia artificial
https://elpais.com/economia/2025-08-25/musk-denuncia-a-apple-y-openai-por-impedir-la-competencia-en-inteligencia-artificial.html
Elon Musk’s xAI sues Apple, OpenAI alleging scheme to suppress competition
https://abcnews.go.com/Business/elon-musks-xai-sues-apple-openai-alleged-scheme/story?id=124956866
Elon Musk sues Apple and OpenAI, claiming unfair AI market practices
https://qz.com/elon-musk-isues-apple-openai

Docker DesktopにCritical脆弱性、CVE-2025-9074 ─ macOS・Linuxも含め更新推奨

コンテナ技術は、開発から運用まで幅広い現場で欠かせない存在となっています。その中でも Docker Desktop は、Windows・macOS・Linux などの環境で簡単に Docker を利用できるツールとして、多くの開発者やエンジニアに利用されています。日常的にローカル開発環境を立ち上げたり、テスト用に複数のコンテナを起動したりする用途で広く普及しており、影響範囲は非常に大きいと言えます。

今回報告された脆弱性 CVE-2025-9074 は、そうした日常的に利用される開発環境に潜む重大なリスクです。影響は特定の設定や条件に限定されず、Enhanced Container Isolation（ECI）や「Expose daemon」設定の有無にかかわらず影響を受けることが判明しています。これにより、普段はセキュアだと考えていた環境でも、不正アクセスやコンテナ制御の乗っ取りといった深刻な被害に発展する可能性があります。

特に Windows 環境では、WSL を介したホストドライブへのアクセスが可能になるなど追加的なリスクが確認されていますが、macOS や Linux でも同様にコンテナ間の不正制御が可能になるため、「Windows ユーザーだけが対象」ではなく、すべての Docker Desktop ユーザーが直ちにアップデートすべき事案です。

Docker 側は迅速に修正版をリリースしており、2025年8月20日に公開された Docker Desktop 4.44.3 で本脆弱性が修正されています。本記事では、脆弱性の詳細とリスク、そしてユーザーが取るべき対策について整理します。

脆弱性の概要

今回報告された CVE-2025-9074 は、Docker Desktop 上で稼働する Linux コンテナが、本来アクセスできないはずの Docker Engine API に直接アクセスできてしまうという脆弱性です。Docker Engine API はコンテナのライフサイクル管理やイメージ操作などを行うための強力なインターフェースであり、ここに不正アクセスされると、ユーザーの意図しない操作が可能になってしまいます。

この問題の本質は、Docker Desktop が内部で利用している サブネット経由の通信経路にあります。通常であれば、セキュリティ設定やネットワークの分離によってコンテナからホスト側の管理 API へ直接到達できないように設計されています。しかし、今回の脆弱性では、その設計をすり抜ける形でアクセスが可能となり、結果として以下のようなリスクが生じます。

不正なコンテナ制御: 攻撃者が任意に新しいコンテナを生成したり、既存コンテナを停止・削除したりできる。
イメージの操作: ローカルに保存された Docker イメージを削除、改ざん、あるいは外部に流出させる可能性。
設定の改変: 環境構築や開発に利用する設定を不正に変更される危険性。

さらに問題を深刻化させているのは、この挙動が ECI（Enhanced Container Isolation）や「Expose daemon」の設定有無に依存しない という点です。つまり、セキュリティオプションを強化していたとしても、今回の脆弱性を防ぐことはできません。

また、Windows 環境においては、WSL バックエンドを利用している場合、通常は制御できない ホストドライブがユーザー権限でマウントされる リスクが確認されています。これはシステム内のファイルが意図せず外部から参照・改変されることにつながり、開発用 PC の安全性を直接脅かす可能性があります。

一方で macOS や Linux 環境においても、Docker Engine API の権限を奪取されれば同様にコンテナ制御やイメージ操作が行われるため、プラットフォームに依存しない深刻な脅威となっています。

今回の脆弱性は CVSS v4.0 ベーススコア 9.3（Critical） として評価されており、最も高い深刻度レベルに分類されています。この評価は、単なる理論的リスクではなく、現実に悪用された場合の影響が極めて広範囲かつ深刻であることを意味しています。

影響範囲

今回の脆弱性 CVE-2025-9074 は、Docker Desktop を利用しているすべてのユーザーに影響を与える可能性があります。特定の環境や利用方法に限定された問題ではなく、Windows・macOS・Linux のいずれにおいても共通してリスクが存在する点が重要です。

まず Windows 環境については、特に WSL（Windows Subsystem for Linux）をバックエンドとして利用している場合に深刻な追加リスクが指摘されています。WSL 上の Linux コンテナからホストマシンのドライブをユーザー権限でマウントされる可能性があり、これによって開発者が扱うソースコードや機密データが不正に参照・改変される危険性が生じます。これは通常のコンテナ分離モデルでは想定されない挙動であり、ローカル開発環境全体が攻撃者に乗っ取られる可能性を意味します。

一方で macOS や Linux 環境でも安心はできません。Docker Engine API へのアクセスが可能になる点は共通しており、攻撃者がこの API を操作することで、以下のようなリスクが発生します。

不正なコンテナの生成・削除・停止などによる環境の破壊
ローカルに保存された Docker イメージの不正利用や流出
開発環境に必要な設定やデータの改変によるサービス停止や混乱

つまり、「Windows 以外の環境では被害が軽い」とは言えず、開発環境に依存するすべてのユーザーが影響を受ける可能性があるのです。Docker Desktop は開発者にとって日常的に利用するツールであり、ローカル環境のコンテナ基盤そのものが脆弱化するという点で、被害の範囲は単一コンテナにとどまらず、開発プロジェクト全体、さらには組織内のリポジトリや CI/CD パイプラインに波及するリスクを孕んでいます。

加えて、今回の脆弱性は ECI（Enhanced Container Isolation）や「Expose daemon」設定の有無に依存せず影響するため、「セキュリティ機能を有効化しているから安全」と考えていたユーザーも例外ではありません。むしろ、多くの利用環境で普段通りにコンテナを実行しているだけで影響を受けるため、利用者全体を巻き込む普遍的な問題と言えます。

結論として、この脆弱性は 「Docker Desktop を利用するすべてのユーザーが対象」であり、特定のプラットフォームや構成に限定されたリスクではありません。そのため、Windows だけでなく macOS や Linux を利用している開発者やエンジニアも例外なく、迅速なアップデート対応が求められます。

対策

今回の脆弱性 CVE-2025-9074 に対しては、Docker 社がすでに修正版を公開しており、Docker Desktop 4.44.3 以降にアップデートすることで解消されます。現地時間 2025 年 8 月 20 日にリリースされたこのバージョンには、脆弱性を突いた不正アクセス経路を封じる修正が含まれており、ユーザー側で追加の設定変更を行う必要はありません。

重要な点は、設定や回避策では問題を防げないということです。ECI（Enhanced Container Isolation）の有効化や「Expose daemon」の無効化など、従来のセキュリティオプションを組み合わせてもこの脆弱性を防ぐことはできません。根本的な対策は Docker Desktop 自体を更新することに尽きます。

アップデート手順

１．現在のバージョンを確認

ターミナルで以下を実行し、Docker Desktop 4.44.3 以上であるかを確認します。

docker version

または、Docker Desktop Dashboardの右下に表示されているバージョンが4.44.3以上になっていることを確認します。

２．最新版の入手

Docker の公式サイト（https://www.docker.com/products/docker-desktop）から最新版をダウンロードします。Docker Desktop Dashboardの通知からでもダウンロード可能です。

３．Docker Desktopのアップデート

Windows / macOS: インストーラを実行し、既存の Docker Desktop に上書きインストール。
Linux: パッケージマネージャ（例: apt や dnf）を利用して更新、もしくは公式のインストーラを再適用。

４．アップデートの実行

右下がUpdateという表示になっている場合、これをクリックしてアップデートを行ってください。Software Updateページが表示されるので、更新を実施してください。

５．アップデート後の確認

再度 docker version を実行し、クライアント・サーバともに 4.44.3 以上であることを確認。
念のため、既存のコンテナが正常に動作するかテスト。

運用上の留意点

全環境での更新を徹底: 個人開発環境だけでなく、チームメンバーや CI/CD 用のビルド環境など、Docker Desktop を利用しているすべての端末で更新が必要です。
旧バージョンの利用を避ける: 脆弱性が公開されているため、旧バージョンを使い続けると攻撃者に狙われやすくなります。
定期的なバージョンチェック: Docker Desktop は短いリリースサイクルで更新されるため、今回の件を機に定期的にバージョン確認を行い、常に最新を維持する運用を推奨します。
CI/CD パイプラインの確認: ビルド環境やテスト環境で Docker Desktop を利用している場合、更新漏れがあるとチーム全体のリスクにつながるため、パイプラインの実行ホストも忘れずに更新してください。

結論として、唯一の有効な対策は速やかなアップデートです。Windows 環境だけでなく macOS・Linux を含むすべての開発環境で Docker Desktop を利用しているユーザーは、今すぐバージョン確認を行い、必要に応じて更新を実施することが強く推奨されます。

おわりに

今回明らかになった CVE-2025-9074 は、Docker Desktop の根幹である Docker Engine API へのアクセス制御に関わる重大な脆弱性であり、影響範囲は Windows・macOS・Linux を含むすべての利用者に及びます。特定の環境に限定された問題ではなく、普段の開発作業やテスト環境、さらには CI/CD パイプラインにまで影響する可能性がある点が非常に危険です。

特に Windows 環境では WSL を介したホストドライブへのアクセスが可能になるなど追加的なリスクがありますが、これはあくまで一部の強調事例であり、macOS や Linux 環境でも Docker Engine API を乗っ取られることで同等の深刻な被害が生じ得ます。したがって、「Windows 以外は安全」と考えるのは誤りです。開発者がどの OS を利用していようと、この脆弱性を軽視すべきではありません。

Docker 社は迅速に修正版を提供しており、2025 年 8 月 20 日公開の Docker Desktop 4.44.3 で問題は解消されています。今回の事例から学べる重要な教訓は、脆弱性対策は「設定や部分的な防御策では不十分」であり、ソフトウェアを常に最新の状態に保つことこそが最も確実な防御策であるという点です。

また、個人開発者だけでなく、組織として Docker Desktop を利用している場合は、全メンバーの環境を一斉に更新する体制が不可欠です。ひとりでも古いバージョンを使い続ければ、その環境が攻撃者に狙われ、結果的にプロジェクト全体のセキュリティを損なう恐れがあります。特にクラウド連携やソースコード管理リポジトリと接続している開発環境では、被害が企業全体に波及する可能性すらあります。

さらに、今回の脆弱性に限らず、日常的なセキュリティ対策として 安全性が確認されていない不明なコンテナイメージを軽率に起動しない ことも重要です。公式リポジトリや信頼できる配布元以外から入手したコンテナには、脆弱性を悪用するコードやマルウェアが含まれる可能性があります。OS やツールを最新化することと同様に、利用するコンテナの信頼性を確認することも忘れてはなりません。

結論として、今すぐ Docker Desktop のバージョンを確認し、4.44.3 以上に更新することが最優先の対応です。加えて、怪しいコンテナを不用意に起動せず、信頼できるソースのみを利用することが、Docker 環境全体の安全を守るうえで不可欠な行動となります。

参考文献

Security NEXT「Docker Desktopに深刻な脆弱性、LinuxコンテナからAPIアクセス可能に — CVE-2025-9074」
https://www.security-next.com/173609
Docker Docs「Docker Desktop release notes」
https://docs.docker.com/desktop/release-notes/
NVD（National Vulnerability Database）「CVE-2025-9074」
https://nvd.nist.gov/vuln/detail/CVE-2025-9074
CVE.org「CVE-2025-9074」
https://www.cve.org/CVERecord?id=CVE-2025-9074

まずはこれだけ！GitHub Copilotの使い方

GitHub Copilot を最大限活かせるように基本的な使い方を学びましょう。

本記事では、 Visual Studio Code での操作を中心に説明していますが、ショートカットについてはIntelliJ IDEA や PyCharm などのJetGBrains 系のIDEについても掲載しています。

回答する言語を指定する

英語で回答してほしいときは特に設定変更する必要はありませんが、日本語で回答してほしいときに、毎回「日本語で回答してください」などと書くのは面倒です。GitHub Copilot では、回答する言語を指定することが可能です。

Visual Studio Code の場合は Settings > Extensions > GitHub Copilot で、Github > Copilot > Chat: Locale Overridesの設定を変更することで、指定した言語で回答を求めることができます。

デフォルトはautoになっていると思いますので、日本語で回答してほしければja に変更してください。

IntelliJ IDEA や PyCharm などでは、 Settings > Languages & Frameworks > GitHub Copilot で、Chat欄のNatural Languageを日本語に変更することで、日本語で回答を求めることができます。

3つのツールを状況に応じて使い分ける

ここでは、以下の3つのツールの使い分けについて説明します。

インラインチャット
チャットパネル
ChatGPT などの対話型生成AIサービス

インラインチャット

チャットパネルを起動してもよいのですが、インラインチャットを使うことでより素早くコードを生成したり、改善したりできます。

Visual Studio Code で、インラインチャットを起動するには、Cmd+I（Win+I）のショートカットキーを使用します。

IntelliJ IDEA や PyCharm では、Ctrl+Shift+I（Ctrl+Shift+G）で同様の操作ができます。

チャットパネル

チャットパネルを使用すると、ワークスペースに関する質問ができるため、説明を求めたい場合にはこちらを使用します。後述のChatGPTなどの対話型生成AIサービスでもソースコードを添付すれば似たようなことができますが、手間なくできる点ではこちらを使用するのがよいでしょう。

チャットパネルは、Cmd+Shift+I（Ctrl+Shift+I）で開閉できます。会話後、コードに復帰したいときはチャットパネルを閉じることですぐにコーディングに戻れます。

IntelliJ IDEA や PyCharm では、Ctrl+Shift+C（Windowsも同様）で、チャットパネルの開閉ができます。

ChatGPTなどの対話型生成AIサービス

一方、ワークスペースに依らない問題の解決方法を質問したいとかであれば GitHub Copilot Chat ではなく、 ChatGPT などを使う方が効率的です。これは GitHub Copilot Chat ではコーディングに関する内容にのみ答えてくれるという点が影響しており、会話の途中で答えてくれなくなることはストレスになるので、使い分けをした方がよいのではないかと思います。

現時点ではアプリ版かWeb版を使うことになるかと思います。ChatGPT 以外にもツールはたくさんありますので、使いやすいものを選択してください。

コードを生成する

インラインチャットを含めたコード生成のパターンを考えます。

適切な名称をつけてコードを生成してもらう

もっとも基本的な生成の仕方になります。関数を生成する場合、適切な関数名をつけることでその関数名に沿ったコードを生成してくれます。

たとえば、JavaScriptで2つの数を加算する関数を作成する場合、addTwoNumbersという名前をつけることで2つの引数と加算をするコードが生成されます。

function addTwoNumbers と入力すると、候補が表示されます。TABキーでこれを確定すると関数が完成します。

コメントをつけて生成してもらう

実現したいことをコメントで書いて、その内容にあったコードを生成させます。

コメントを書いてから改行すると、そのコメントにあったコードが生成されます。

生成された内容が問題なければ、TABキーで確定させます。

候補が表示されているとき、マウスカーソルをカーソルをホバーすると、生成するコードの他の候補に切り替えられます。

これを表示しなくても、Option+[（Alt+[）とOption+]（Alt+]）で前の候補と次の候補を行き来でき、生成したい候補でTABキーで確定できます。最初に生成されたコードが期待したコードでなくても別の候補が期待したコードである可能性があるので、切り替えて確認するとよいでしょう。

コードを書きながらコードを生成してもらう

これがもっともよく使われている方法かもしれません。コードを書きながらその次のコードを生成してもらう方法です。

同じようなコードを生成する場合や常套句のようなコードを生成する場合には高い精度のコードを生成してくれますが、意図が正しく伝わっていないと期待したコードを生成してくれないので、後述のインラインチャットでコード生成を指示するのがよいと思います。

インラインチャットでコード生成を指示する

適切な関数名が思いつかなくてもコメントを書かなくてもインラインチャットを使うことでコードの生成を指示できます。

ENTER（RETURN）キーで生成してくれます。

Visual Studio Code では、再生成したければCmd+R（Win+R）、受け入れるならCmd+ENTER（Win+RETURN）を押下します。IntelliJ IDEA や PyCharm ではショートカットは用意されていないようで、マウス操作で再生成し、

受け入れるなら、同様にマウス操作で

エディタに反映します。

インラインチャットでコードを書き換えてもらう

書き換えてほしいコードを選択し、インラインチャットで書き換えてほしい内容を入力することでコードの改善ができます。とりあえず書いたコードにバグがあったり、非効率なコードだったりするときに改善してもらうことができるので便利です。

修正してほしいコードを範囲選択し、インラインチャットを起動、修正後どうなってほしいかを伝えます。

候補が表示されるので、

問題なければCmd+ENTER（Win+RETURN）で確定します。

文章による説明を求める必要がなく、さっさと修正したい場合はチャットパネルではなくインラインチャットを使う方が効率よくコーディングを進められます。

何をするかを指定する

文章で書かなくてもコマンドを使ってやってほしいことを指定することができます。

/generate

実際には文章で書いても手間ではなく、先にコメントを書いておけば生成してくれるので、使う機会はほぼないかもしれませんが、Visual Studio Code ではコード生成をするコマンドがあります。

/generateを使って作成してほしいコードの仕様を伝えると、

以下のようにコードを生成してくれます。

IntelliJ IDEA や PyCharm ではこのコマンドはないようですので、ご注意ください。

/fix

修正についても文章で書いてもそれほど手間ではないので使う機会は多くないですが、/fixコマンドを使うことで修正を指示することができます。

/fixコマンドに続いて修正してほしいことを記述することで、

修正結果を表示してくれます。

このコマンドは IntelliJ IDEA や PyCharm でも使用可能です。

/explain

コードやワークスペースが何を行っているのかを説明・要約してもらうことで、コードを一から読むよりも理解が早くなります。たとえば、業務で自分が関わったことのない古いコードがある場合、そのコードについて説明をしてもらってからコードを読んだ方が理解しやすいと思います。

説明はインラインチャットではなくチャットパネルで聞いた方がわかりやすいです。

チャットパネルを開くと、現在エディタで表示しているファイルが選択済みなので、このまま/explainコマンドを指定します。

説明の中で不明な点や深掘りしたい点があれば、チャットで追加質問してください。

このコマンドは IntelliJ IDEA や PyCharm でも使用可能です。

/doc

これまではクラスやメソッドのコメントを書くこともメンテナンスすることも非常にコストの高い作業だったと思います。生成AIの登場でこのような問題は過去のものとなりつつあります。

関数の先頭で以下のように/docコマンドを使用すると、

以下のようにドキュメントテーションコメントを生成してくれます。

コメントが古くて最新化したい場合でも/docコマンドが使用できます。以下のようにドキュメンテーションコメントが適切にメンテナンスされていない場合でも、コメントと関数を範囲指定して/docコマンドを使うと、

以下のようにコメントを生成し直してくれます。

このコマンドは IntelliJ IDEA や PyCharm でも使用可能です。

/tests

主にGitHub Copilot Chatで使用しますが、テスト対象を選択してテストコードを生成することができます。ただし、注意したいのは、テストの準備にプロジェクト固有の特殊が必要な場合にはうまく生成されないことがあります。

基本的には、最初の１つはコード補完を使いながら自身で作成し、その派生形で記述できる他のバリエーションを指示しながら作成するのがよいでしょう。テストで使用している値についても細かく指示するよりは一旦生成させて自身で修正した方が早い場合があります。

その他のコマンド

上記以外にもいくつかのコマンドがあります。

Visual Studio Code では、コード編集を行うための /edit コマンドが用意されています。

IntelliJ IDEA や PyCharm ではコードをシンプルにするための/simplyfy コマンドが用意されていますが、冗長なコードという点であれば、IDE自体の機能で修正できる場合もありますので、それほど使用頻度は高くないと思います。

何を参照するかを指定する

何を参照するのかを明示的に指定することで、精度の高い回答を得ることができます。これらはVisual Studio Code のみで使用可能ですが、ファイルだけはIntelliJ IDEA や PyCharm でもマウス操作で追加することができます。

@workspace

ワークスペース内のソースコードをすべて参照し、関連性の高いファイルをピックアップしてコードや回答を生成します。説明上、この記事中ではワークスペースという表現に統一していますが、ワークスペースでもプロジェクトでも伝わりますので、特に気にする必要はありません。

@vscode

Visual Studio Code 限定の機能になりますが、Visual Studio Codeの機能に着目した回答をしてくれます。設定やショートカットキーに関する質問をしたい場合は、@vscodeをつけるようにしてください。会話の中で設定に遷移するボタンも出力してくれるので、こちらも活用してみてください。

Show in Settings Editorをクリックすると、

設定が表示されます。

@terminal

コードの話ではなく、コマンドに関する質問をしたい場合は、ターミナルに着目した回答をしてくれる@terminalを使うのがよいでしょう。

#file

参照してほしいファイルを指定します。基本的にはアイコンをクリックしてファイルを選ぶのがよいでしょう。基本的に単独で使用可能ですが、もし効かないようであれば@workspaceと併用してください。

#editor

エディタの表示領域を含めるには#editorを使用します。ただし、現在エディタで表示しているファイルはデフォルトで参照していることがほとんどなので、あまり使う機会はないかもしれません。

#selection

エディタの選択箇所を参照します。IntelliJ IDEA や

#terminalLastCommand

ターミナルで最後に実行したコマンドとその実行結果を参照します。非常に便利な機能ですが、

#terminalSelection

ターミナルの選択箇所を参照します。コマンドを実行していてエラーが出たときに対処方法を聞くときは#terminalLastCommandで構いませんが、もう少しピンポイントで聞きたいときは#terminalSelectionを使うとよいでしょう。

目的別プロンプト集

いくつか、よく使いそうなプロンプト例をまとめてみました。これらはGitHub Copilot Chatで使用します。

ワークスペース全体を説明してもらう

/explainコマンドと@workspaceを組み合わせることで、ワークスペース全体について説明してもらうことができます。

@workspace /explain

新しく参画したメンバーが担当するワークスペースの構造を把握する際にとても有用だと思います。オンボーディング中やオンボーディング後の自習時間に使ってみてはいかがでしょうか。

ワークスペースのディレクトリ構造を明らかにする

ワークスペースのディレクトリ構造に可視化したいときは、以下のように聞くとよいです。

@workspace /explain ワークスペースのディレクトリ構造を教えて

こちらも、どこにどんなファイルがあるのかをディレクトリ構造を把握したい場合に有効な方法です。

コードレビューをしてもらう

作成したコードに対してコードレビューを行ってもらうのも有効な使い方のひとつです。

コードレビューを行う場合は、包括的なレビューをするのか、特定の何かについてレビューをするのかを明確にすることが重要です。

包括的なレビューを行ってほしい場合

たとえば、改善すべて点はありますかと質問するとよりよくするためのアドバイスを回答してもらうことができます。この方法は、最初のレビューや最終的なレビューとして使うとよいでしょう。

特定の観点に基づいてレビューを行ってほしい場合

特定の観点についてレビューをしてもらうことで、改善すべき点をより明確にすることができます。

具体的には、コード品質（命名規則、冗長なコード、可読性）、セキュリティ、パフォーマンスなどの問題を指摘してもらうのがよいと思います。

命名は適切ですか
冗長なコードや簡潔に書けるコードはありますか
エラーハンドリングは適切ですか
実装漏れやデバッグコードなどは残っていませんか
脆弱性はありますか
パフォーマンスの問題はありますか
不足しているテスト観点はありますか

これ以外にも、プロジェクト固有の観点（特定の機能が実装されているか、など）を確認するのもよいでしょう。

また、レビューア側でも目視によるレビューと併用するのもよいと思います。

まとめ

当然といえば当然ですが、 GitHub Copilotの機能はVisual Studio Codeがもっとも充実しています。ただ、EclipseやIntellJ IDEA など他のIDEでもまったく使えないわけではないため、もし使っているのであれば積極的に活用していくことが重要です。

GitHub Copilotを活用にするには、基本的なショートカットやコマンドなどを理解することももちろんですが、やってほしいことを明確に指示することが大切です。これはインラインチャットで指示するだけでなく、コメントを書いてからコードを書き始めるということも含みます。

Copilot や AI Agent 関連はかなり活発に進化しています。この記事で紹介した機能以外もありますし、今後もっとよいやり方が出てくることも容易に想像できます。コーディングの生産性を高めるため、定期的にキャッチアップが必要だと思います。

IntelliJ IDEAで次の出現箇所を選択する

Visual Studio Codeでの❖+D/⌘+Dのような現在選択しているテキストと同じテキストが出現する次の箇所を選択するショートカットは、IntelliJ IDEAにも存在します。

ただ、WindowsとmacOSでショートカットが異なるので両方を使用している方は注意が必要です。

Windowsの場合

WindowsのIntelliJ IDEAでは、Alt+Jで現在選択しているテキストと同じテキストが次に出現する箇所を選択することができます。

macOSの場合

macOSのIntelliJ IDEAでは、^+Gで現在選択しているテキストと同じテキストが次に出現する箇所を選択することができます。

Linuxの場合

最近では開発用マシンとして使用している人もいるので、ちょっと調べてみました。Ubuntu 24.04 ARM64で動作確認を行っていますが、他のディストロやCPUでも変わらないかと思います。

結論からいうと、Windowsと同じAlt+Jで同様の操作ができました。macOSだけが異なるショートカットになっているため、こちらについても意識しておいた方がよいでしょう。

まとめ

Visual Studio Codeとは異なり、IntelliJ IDEAをはじめとするJetBrainsの製品はWindowおよびLinuxとmacOSでショートカットが異なります。これはCtrlキーとcommandキーの違いというような差異ではなく、使用するアルファベット自体が異なっている（まったくの別ショートカットとなっている）点に注意が必要です。

特に、私のようにプライベートと仕事で使用OSが異なる人は混乱しやすいと思いますので、OSを揃えるようにするなど何かしらの対策をしておいた方がよいかもしれません。

pipxでPoetryをインストールする

公式サイトでのPoetryのインストール方法の一つにpipxを使ったインストール方法があって、それが気になったので、pipxを導入してPoetryをインストールしていこうと思います。手順はmacOSの場合になります。

pipxのインストール

github.com

GitHub – pypa/pipx: Install and Run Python Applications in Isolated Environments

Install and Run Python Applications in Isolated Environments – pypa/pipx

Homebrewを使ってpipxをインストールします。

$ brew install pipx
==> Downloading https://formulae.brew.sh/api/formula.jws.json
##O=-#      #
==> Downloading https://formulae.brew.sh/api/cask.jws.json
##O=-#      #
==> Downloading https://ghcr.io/v2/homebrew/core/pipx/manifests/1.3.3
Already downloaded: /Users/t0k0sh1/Library/Caches/Homebrew/downloads/af94290372652b3f23470aa9b2dc3e6cc6f6ac908d786fa0b2ccf9c0f53db957--pipx-1.3.3.bottle_manifest.json
==> Fetching pipx
==> Downloading https://ghcr.io/v2/homebrew/core/pipx/blobs/sha256:31547c41734fa46c13276ada25e3e8548db97281d0c513b9cdcb5268adcc74ff
Already downloaded: /Users/t0k0sh1/Library/Caches/Homebrew/downloads/a4c05e49cf7f84a6647e146f9d68d9983028ea48180d87771a41cdb1f5d27b45--pipx--1.3.3.arm64_sonoma.bottle.tar.gz
==> Pouring pipx--1.3.3.arm64_sonoma.bottle.tar.gz
==> Caveats
zsh completions have been installed to:
  /opt/homebrew/share/zsh/site-functions
==> Summary
🍺  /opt/homebrew/Cellar/pipx/1.3.3: 108 files, 697.7KB
==> Running `brew cleanup pipx`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

インストール後、pipx ensurepathコマンドを実行します。

$ pipx ensurepath
Success! Added /Users/t0k0sh1/.local/bin to the PATH environment variable.

Consider adding shell completions for pipx. Run 'pipx completions' for instructions.

You will need to open a new terminal or re-login for the PATH changes to take effect.

Otherwise pipx is ready to go! ✨ 🌟 ✨

上記メッセージ中に、

You will need to open a new terminal or re-login for the PATH changes to take effect.

とあるので、新しいターミナルを開くかログインし直す必要があります。今回はこのままインストールを進めたいので、設定ファイルを読み込み直します。

$ exec $SHELL -l

これでインストールは完了です。

activate-global-python-argcompleteのlinkでエラー

Homebrewでインストールする際に以下のエラーに遭遇しました。

Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /opt/homebrew
Could not symlink bin/activate-global-python-argcomplete
Target /opt/homebrew/bin/activate-global-python-argcomplete
already exists. You may want to remove it:
  rm '/opt/homebrew/bin/activate-global-python-argcomplete'

To force the link and overwrite all conflicting files:
  brew link --overwrite python-argcomplete

To list all files that would be deleted:
  brew link --overwrite --dry-run python-argcomplete

事象としては、activate-global-python-argcompleteのsymlinkに失敗したようです。解消方法としてはいくつかありますが、ここでは一番最初に書かれている/opt/homebrew/bin/activate-global-python-argcompleteを削除する方法で進めます。

指示どおりに対応してきます。まずは、activate-global-python-argcompleteが存在するかをチェックします。

$ ls /opt/homebrew/bin/activate*
/opt/homebrew/bin/activate-global-python-argcomplete

存在していることを確認できました。これを削除します。

$ rm /opt/homebrew/bin/activate-global-python-argcomplete
$ ls /opt/homebrew/bin/activate*
zsh: no matches found: /opt/homebrew/bin/activate*

削除されたことを確認しました。では、元の手順に戻って、再度pipx installコマンドを実行します。

Poetryをインストールする

python-poetry.org

Introduction | Documentation | Poetry – Python dependency management and packaging made easy

Introduction Poetry is a tool for dependency management and packaging in Python. It allows…

pipxを使ってPoetryをインストールします。

$ pipx install poetry
  installed package poetry 1.7.1, installed using Python 3.12.1
  These apps are now globally available
    - poetry
⚠️  Note: '/Users/t0k0sh1/.local/bin' is not on your PATH environment variable. These apps will not be globally accessible until your PATH is updated. Run `pipx ensurepath` to automatically add it, or
    manually modify your PATH in your shell's config file (i.e. ~/.bashrc).
done! ✨ 🌟 ✨

インストール後、コマンドが使えるようになっていることを確認します。

$ poetry -V
Poetry (version 1.7.1)

これでPoetryのインストールは完了しました。

まとめ

pipxのインストールで少しトラブルがありましたが、比較的簡単にインストールを進めることができました。

PYthon製のCLIをインストールする際は、pipxを使っていくのが良さそうです。

Apple Silicon MacにStable Diffusion WebUIをインストールする

Stable DiffusionをApple SiliconのmacOSにインストールしてみましたが、少しコツが必要でした。

インストール時期やApple Siliconの種類によっては若干変わるかもしれませんが、私がM1 Maxチップ搭載のMacBook Proで成功した手順をまとめてみました。

必要なパッケージをインストールする

こちらは公式に従ってインストールします。私の環境では最終的にPythonはここでインストールしたものではなく、Asdfで導入したものを使用しているので、3.10系であればここでインストールしなくてもよいと思われます。

brew install cmake protobuf rust python@3.10 git wget

Stable Diffusion WebUIをダウンロードする

GithubのReleasesでもダウンロードできそうですが、macOSの場合はリポジトリをクローンする必要があります。

任意のディレクトリにリポジトリをcloneしてください。

git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui

追加データをダウンロードする

手順の中でここが一番面倒かもしれません。ここでは執筆時点最新のv2.1を使用します。

huggingface.co

stabilityai/sd-vae-ft-mse-original at main

We’re on a journey to advance and democratize artificial intelligence through open source …

上記サイトからvae-ft-mse-840000-ema-pruned.ckptというファイルをダウンロードし、stable-diffusion-webui/models/Stable-difusionに保存してください。

保存後、ファイル名をv2-1_768-ema-pruned.vae.ptに変更してください。

huggingface.co

stabilityai/stable-diffusion-2-1 at main

We’re on a journey to advance and democratize artificial intelligence through open source …

上記サイトからv2-1_768-ema-pruned.safetensorsというファイルをダウンロードし、stable-diffusion-webui/models/Stable-difusionに保存してください。

ここを開いて、表示された内容をコピーし、stable-diffusion-webui/models/Stable-difusionにv2-1_768-ema-pruned.yamlというファイル名で保存してください。

Stable Diffusion WebUIを起動する

cd stable-diffusion-webui
./webui.sh

起動すると、以下のようなログが表示されます。URLが出ているので、ここにアクセスしてください。

Model loaded in 3.6s (load weights from disk: 0.3s, create model: 0.2s, apply weights to model: 1.8s, apply half(): 0.6s, load VAE: 0.1s, move model to device: 0.5s).
Running on local URL:  http://127.0.0.1:7860

To create a public link, set `share=True` in `launch()`.
Startup time: 11.2s (import torch: 2.1s, import gradio: 1.7s, import ldm: 0.4s, other imports: 2.9s, load scripts: 0.3s, load SD checkpoint: 3.6s, create ui: 0.2s).

ブラウザでアクセスすると、以下のような画面が表示されます。

設定変更を行う

同じようにApple Silicon Macにインストールしている方の記事で、この点に触れていない方も結構見かけるので、もしかすると環境依存かもしれませんが、私の環境ではv2.1でGenerateしようとすると以下のようなエラーが表示されました。

  0%|                                                                                                                                                                                                                                    | 0/20 [00:02<?, ?it/s]
Error completing request
Arguments: ('task(6gvckovujc9xon0)', 'sailing ship', '', [], 20, 0, False, False, 1, 1, 7, -1.0, -1.0, 0, 0, 0, False, 512, 512, False, 0.7, 2, 'Latent', 0, 0, 0, [], 0, False, False, 'positive', 'comma', 0, False, False, '', 1, '', 0, '', 0, '', True, False, False, False, 0) {}
Traceback (most recent call last):
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/call_queue.py", line 56, in f
    res = list(func(*args, **kwargs))
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/call_queue.py", line 37, in f
    res = func(*args, **kwargs)
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/txt2img.py", line 56, in txt2img
    processed = process_images(p)
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/processing.py", line 503, in process_images
    res = process_images_inner(p)
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/processing.py", line 653, in process_images_inner
    samples_ddim = p.sample(conditioning=c, unconditional_conditioning=uc, seeds=seeds, subseeds=subseeds, subseed_strength=p.subseed_strength, prompts=prompts)
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/processing.py", line 869, in sample
    samples = self.sampler.sample(self, x, conditioning, unconditional_conditioning, image_conditioning=self.txt2img_image_conditioning(x))
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/sd_samplers_kdiffusion.py", line 358, in sample
    samples = self.launch_sampling(steps, lambda: self.func(self.model_wrap_cfg, x, extra_args={
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/sd_samplers_kdiffusion.py", line 234, in launch_sampling
    return func()
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/sd_samplers_kdiffusion.py", line 358, in <lambda>
    samples = self.launch_sampling(steps, lambda: self.func(self.model_wrap_cfg, x, extra_args={
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/venv/lib/python3.10/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
    return func(*args, **kwargs)
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/repositories/k-diffusion/k_diffusion/sampling.py", line 145, in sample_euler_ancestral
    denoised = model(x, sigmas[i] * s_in, **extra_args)
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/venv/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
    return forward_call(*input, **kwargs)
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/sd_samplers_kdiffusion.py", line 152, in forward
    devices.test_for_nans(x_out, "unet")
  File "/Users/t0k0sh1/Workspace/stable-diffusion-webui/modules/devices.py", line 152, in test_for_nans
    raise NansException(message)
modules.devices.NansException: A tensor with all NaNs was produced in Unet. This could be either because there's not enough precision to represent the picture, or because your video card does not support half type. Try setting the "Upcast cross attention layer to float32" option in Settings > Stable Diffusion or using the --no-half commandline argument to fix this. Use --disable-nan-check commandline argument to disable this check.

ちなみに、v1.4やv1.5ではこの事象は起きなかったので、v2.x系固有のエラーかもしれません。

これを解消するために、設定変更を行います。画面上部のタブからSettingsを選択し、

左のメニューからStable Diffusionを選択します。

バージョンにもよるかもしれませんが、一番下にUpcast cross attention layer to float32というチェックボックスがあるので、ここにチェックをつけてください。

最後に設定を反映させるため、画面上部のApply settingsボタンを押してください。

これでエラーが出ずに画像生成ができるようになります。

Apple Silicon MacのDockerでOracle Databaseを動かす

執筆時点（2023/03/01）での暫定的な対応となる点にご注意ください。将来的にはOracle DatabaseがARMに対応する可能性があります。
Oracle DatabaseのARM対応については、以下の動画の26:40 – 27:22をご覧ください。

Oracle Database: What’s new, what’s next

Apple Silicon MacでOracle Databaseを動かす選択肢はいくつかありますが、よく知られている方法は私の環境ではうまく生きませんでした。

ここでは私の環境で成功した方法を共有します。

この方法は、

Running Oracle Database on Docker on Apple M1 Chip

で紹介されている方法になります。

手順を実行するためには、

Homebrew
Docker

が必要となります。

Colimaをインストールする

まずはColimaをインストールします。Dockerの--platform linux/x86_64ではうまくいきませんでしたので、ご注意ください。

$ brew install colima

Homebrewでインストールしますので、インストールしていない場合は先にインストールしてください。

次にColimaを起動します。起動するとDockerのコンテキストが変更されます。

$ colima start --arch x86_64 --memory 4

ここでは参考にした記事と同じく4(GB)のメモリを割り当てていますが、必要に応じて増やしてください。

$ docker context ls
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT                                     KUBERNETES ENDPOINT   ORCHESTRATOR
colima *            moby                colima                                    unix:///Users/user1/.colima/default/docker.sock
default             moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                                               swarm
desktop-linux       moby                                                          unix:///Users/user1/.docker/run/docker.sock

現在のコンテキストがcolimaになっていることを確認してください。変更されていない場合は、

$ docker context use colima

で変更してください。

Oracle Databaseを起動する

Oracle DatabaseをDockerで起動します。

$ docker run -d -p 1521:1521 -e ORACLE_PASSWORD=<パスワード> -v oracle-volume:/opt/oracle/oradata gvenzl/oracle-xe

<パスワード>部分は任意のパスワードを設定してください。このパスワードはSYSユーザーとSYSTEMユーザーのパスワードになります。

例えば、パスワードをpasswordにした場合は以下のようになります。

$ docker run -d -p 1521:1521 -e ORACLE_PASSWORD=password -v oracle-volume:/opt/oracle/oradata gvenzl/oracle-xe

すぐに制御が返ってきますので、少し経ったら接続してみましょう。ローカルにSQL*Plusはインストールされていないと思いますので、何かしらのデータベース接続ツールを使用してください。

私はDataGripを使って接続しています。ユーザーはsystem、パスワードは先ほど起動時に設定したパスワードを入力してください。

まとめ

恐らくこれが現状では最も簡単にApple Silicon MacでOracle Databaseを動作させる方法だと思います。将来的にはVirtualBoxなどでもっと簡単にOracle Databaseを動作させることができるようになる可能性がありますので、暫定的な対応とお考えください。

M1/M2 Macで機械学習の環境を構築する

TensorflowとPytorchがApple Siliconに対応したため、Pythonの機械学習・ディープラーニング環境を構築します。

仮想環境の作成

仮想環境を作成します。

使用するPythonのバージョンですが、このあとインストールするTensorflowが執筆時点では3.7から3.10をサポートしており、Pytorchが3.7以上をサポートしているため、3.10を使用することにします。

conda create -n datascience python=3.10
conda activate datascience

ここでは仮想環境の名前をdatascienceにしていますが、任意の名前で構いません。

機械学習関連

機械学習関連のパッケージをインストールします。

機械学習でよく使われるパッケージをインストールします。

conda install numpy scipy pandas scikit-learn

代表的な可視化パッケージをインストールします。

conda install matplotlib seaborn plotly

EDAパッケージをインストールします。

conda install -c conda-forge pandas-profiling autoviz sweetviz

ローコード機械学習をインストールします。

conda install -c conda-forge pycaret

Jupyter notebookをインストールします。

conda install notebook

スクレイピング関連

スクレイピングでよく使用されるパッケージをインストールします。

conda install -c conda-forge requests scrapy beautifulsoup4

画像処理関連

画像処理でよく使用されるパッケージをインストールします。

conda install -c conda-forge pillow opencv

ディープラーニング関連

TensorflowとPytorchをインストールします。

Tensorflow

Xcode Command Line Toolをインストールしていない場合は以下のコマンドでインストールします。　

xcode-select --install

Tensorflow dependenciesをインストールします。

conda install -c apple tensorflow-deps

Tensorflowをインストールします。

pip install tensorflow-macos

Metalプラグインをインストールします。

pip install tensorflow-metal

インストール後にGPUが使用可能か確認しましょう。

import sys
import tensorflow.keras
import pandas as pd
import sklearn as sk
import scipy as sp
import tensorflow as tf
import platform

gpu = len(tf.config.list_physical_devices('GPU'))>0
print("GPU is", "available" if gpu else "not available")

以下のように表示されればGPUが使用可能です。

GPU is available

Pytorch

PytorchはTensorflowに比べるとインストールは簡単です。以下のコマンドでインストールします。

pip install --pre torch torchvision --extra-index-url https://download.pytorch.org/whl/nightly/cpu

インストール後にGPUが使用可能か確認しましょう。

import torch

gpu = torch.backends.mps.is_available()
print("GPU is", "available" if gpu else "not available")

以下のように表示されればGPUが使用可能です。

GPU is available

今後の課題

現時点で形態素解析パッケージであるMecabのインストールに失敗しています。手順もいくつか示されていますが、実際に試したところいずれもうまくいっていません（インストール自体に失敗する、インストール後に動作しない）。

こちらは引き続きインストール方法を調査し、判明次第本記事を更新したいと思います。

[macOS] iTerm2で自動的にログを取得する設定を行う

セッション開始時に自動的にログを取得する方法について解説します。

ログの出力先を用意する

作成先はどこでも構いません。使用量にもよりますが、長期間運用しているとそれなりのサイズとなるため、空き容量が少ないストレージや容量が圧迫したときに動作に影響のあるストレージは避けた方がよいでしょう。

特に、容量の少ないMacBookを使用している場合は、すぐにディスクがいっぱいになる場合がありますので、外部の大容量ストレージを使うか、ログを定期的に削除するなどの対策をご検討ください。

本記事では、Google Drive for desktopで作成されるGoogle Driveにログを出力するディレクトリを作成しています。

iTerm2のプロファイル（Profile）を開く

iTerm2のメニューからProfiles > Open Profiles...（Command+O）でProfilesダイアログを開きます。

利用状況にもよりますが、星マークがついているProfile Nameが現在使用しているプロファイル（設定）になります。多くの型はDefaultに星マークがついていると思いますが、私の環境ではGuakeを使用しているため、Guakeプロファイルに星マークがついています。

星マークがついている行を選択し、Edit Profiles...を選択してください。

ProfilesタブのSessionタブに移動し、Miscellaneousの「Automatically log session input to files in:」にチェックをつけ、ログの保存先のディレクトリのパスをテキストボックスに入力します。

変更は保存操作をしなくても即時反映されるため、作業はこれで完了ですので、そのまま閉じてください。

ログが出力されることを確認する

では、実際にセッションを新規作成してログファイルが作成されることを確認してみましょう。

iTerm2のメニューからShell > New Window（Command+N）もしくはShell > New Tab（Command+T）で新しいセッションを開始します。
セッション開始後、Finderでログの出力先にファイルが作成されたことを確認します。

特にファイル名は指定していませんが、ファイル名にセッションを開始した年月日時分秒が含まれていますので、後で探すときに困ることはなさそうです。

では、ファイルを開いてみましょう。ここではテキストエディット.appでファイルを開いています。

Shellの設定によりますが、私の環境ではzshellを使用し、Powerlevel10Kを導入しているため、非常に見にくくなっています。この時点で読める表示になっている方は以降の手順は必須ではありませんが、そうでない方は以降で説明する設定を行ってみてください。

ログをプレーンテキストで出力する

先ほどの設定に戻り、「Log plain text」にチェックをつけます。

これで、再度セッションを開始してログを出力した後で、ログファイルをテキストエディット.appで開いてみます。

多少文字化けしている箇所はありますが、先ほどに比べると圧倒的に読みやすくなっています。

「Log plain text」チェックボックスのON、OFFを両方試していただいて環境にあった方を選択してください。

ISOファイルをUSBフラッシュドライブ（USBメモリ）に書き込む（macOS編）

以前、WindowsでRufusを使って、ISOファイルをUSBフラッシュドライブ（以下、USBメモリ）に書き込む方法をご紹介しました。

今回はmacOSでISOファイルをUSBメモリに書き込む方法を解説します。

USBメモリのディスクデバイスを確認

diskutil listコマンドを使って、マウントしているUSBメモリが割り当てられているディスクデバイスを確認します。

$ diskutil list
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         1.0 TB     disk0
   1:             Apple_APFS_ISC                         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         994.7 GB   disk0s2
   3:        Apple_APFS_Recovery                         5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +994.7 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            15.2 GB    disk3s1
   2:              APFS Snapshot com.apple.os.update-... 15.2 GB    disk3s1s1
   3:                APFS Volume Preboot                 350.0 MB   disk3s2
   4:                APFS Volume Recovery                804.6 MB   disk3s3
   5:                APFS Volume Data                    107.5 GB   disk3s5
   6:                APFS Volume VM                      20.5 KB    disk3s6

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *7.9 GB     disk4
   1:             Windows_FAT_32 UBUNTU-SERV             7.9 GB     disk4s1

上記の場合、/dev/disk4が今回ISOファイルを書き込むUSBフラッシュドライブ（USBメモリ）です。すでに過去に書き込み済みのUSBメモリであれば名前（NAME）、そうでない場合は容量（SIZE）等で判断してください。

USBメモリを初期化する

ディスクデバイスが誤っていないかを十分に確認のうえ、diskutil eraseDiskコマンドでUSBメモリを初期化します。

$ diskutil eraseDisk FAT32 UBUNTU2204 /dev/disk4
Started erase on disk4
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Formatting disk4s2 as MS-DOS (FAT32) with name UBUNTU2204
512 bytes per physical sector
/dev/rdisk4s2: 15023424 sectors in 1877928 FAT32 clusters (4096 bytes/cluster)
bps=512 spc=8 res=32 nft=2 mid=0xf8 spt=32 hds=255 hid=411648 drv=0x80 bsec=15052800 bspf=14672 rdcl=2 infs=1 bkbs=6
Mounting disk
Finished erase on disk4

今回使用しているUSBメモリは8GBなので、FAT32でフォーマットしています。
名前（NAME）を指定したので、その名前に変わっているか確認してみましょう。

$ diskutil list
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         1.0 TB     disk0
   1:             Apple_APFS_ISC                         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         994.7 GB   disk0s2
   3:        Apple_APFS_Recovery                         5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +994.7 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            15.2 GB    disk3s1
   2:              APFS Snapshot com.apple.os.update-... 15.2 GB    disk3s1s1
   3:                APFS Volume Preboot                 350.0 MB   disk3s2
   4:                APFS Volume Recovery                804.6 MB   disk3s3
   5:                APFS Volume Data                    107.5 GB   disk3s5
   6:                APFS Volume VM                      20.5 KB    disk3s6

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *7.9 GB     disk4
   1:                        EFI EFI                     209.7 MB   disk4s1
   2:       Microsoft Basic Data UBUNTU2204              7.7 GB     disk4s2

タイプ（TYPE）および名前（NAME）が変わっていることからUSBメモリが初期化されたことが確認できます。

マウントを解除する

書き込みを行う前にマウントを解除しておきます。これをしておかないと、ISOファイルを書き込む時にエラーになります。

$ diskutil umountDisk /dev/disk4
Unmount of all volumes on disk4 was successful

デスクトップからUSBメモリのアイコンが消えたかを確認してください。消えていればマウントが解除されています。

ISOファイルをUSBメモリにコピーする

では、ISOファイルをUSBメモリにコピーしていきましょう。USBメモリへの書き込みにはddコマンドを使用します。

書き込みの際にはディスクデバイスが正しいことを十分確認のうえ行ってください。
また、ddコマンド実行時にsudoコマンドを併用する場合、カレントディレクトリを表す”~“を使用すると正しいパスにならない場合がありますので、フルパスで指定したり、ISOファイルのあるディレクトリに移動してから実行してください。
ddコマンドのデフォルトブロックサイズが512なので、本例では、1M（1MB）に増やして実行しています。

$ sudo dd if=/Users/t0k0sh1/Downloads/ubuntu-22.04-live-server-amd64.iso of=/dev/disk4 bs=1M
1398+1 records in
1398+1 records out
1466714112 bytes transferred in 148.687247 secs (9864424 bytes/sec)

最後に

以上で、USBメモリへの書き込みが完了しました。実際に使用して正しく書き込めていることを確認してください。

本手順ではディスクデバイスの指定を間違わないようにすることが最も重要になります。この点には十分注意して操作を実施してください。

Apple Silicon macOSでディープラーニングの環境を構築する（Miniforge使用、Tensorflow、Tensorflow addons導入）

Apple Silicon（M1、M1Max） macOSでディープラーニングの環境を構築する方法について解説します。

本手順は2022/4/1時点のものです。現状ではHomebrewやPyenv等でインストールしたPythonではTensorflowを導入できないようです。この状況も今後変わってくる可能性があります。

Miniforgeのインストール

現状ではMiniforgeを使うのが最も楽な手順のようです。

MiniforgeのGithubサイトからApple Silicon用のインストーラをダウンロードしてください。ファイル名はMiniforge3-MacOSX-arm64.shとなっています。

迷うところはありませんが、念のため応答する箇所について掲載しておきます。

$ bash ~/Downloads/Miniforge3-MacOSX-arm64.sh                                                                                                                                                           

Welcome to Miniforge3 4.12.0-0

In order to continue the installation process, please review the license
agreement.
Please, press ENTER to continue
>>> ← ENTERを押下
Miniforge installer code uses BSD-3-Clause license as stated below.

 ・・・

Do you accept the license terms? [yes|no]
[no] >>> yes ← yesを入力してENTERを押下

Miniforge3 will now be installed into this location:
/Users/t0k0sh1/miniforge3

  - Press ENTER to confirm the location
  - Press CTRL-C to abort the installation
  - Or specify a different location below

[/Users/t0k0sh1/miniforge3] >>> ← ENTERを押下
PREFIX=/Users/t0k0sh1/miniforge3
Unpacking payload ...

 ・・・

Do you wish the installer to initialize Miniforge3
by running conda init? [yes|no]
[no] >>> no ← noを入力してENTERを押下

You have chosen to not have conda modify your shell scripts at all.
To activate conda's base environment in your current shell session:

eval "$(/Users/t0k0sh1/miniforge3/bin/conda shell.YOUR_SHELL_NAME hook)"

To install conda's shell functions for easier access, first activate, then:

conda init

If you'd prefer that conda's base environment not be activated on startup,
   set the auto_activate_base parameter to false:

conda config --set auto_activate_base false

Thank you for installing Miniforge3!

インストールが完了すると、以下のようなメッセージが表示されています。このうち、YOUR_SHELL_NAME部分を書き換えてシェルの設定ファイルに追記します。

eval "$(/Users/t0k0sh1/miniforge3/bin/conda shell.YOUR_SHELL_NAME hook)"

macOSのデフォルトシェルはzshですので、以下のように書き換えて、.zshrcに追記してください。

eval "$(/Users/t0k0sh1/miniforge3/bin/conda shell.zsh hook)"

conda環境の設定を行う

次にconda環境の設定を行います。

conda環境の自動有効化をOFFにする

前述の作業が完了し、再度シェルにログインすると、自動でconda環境が有効になります。これでも問題ない方は以下の設定変更を行う必要はありませんが、そうでない方はconda環境が自動で有効にならないように設定変更をしてください。

$ conda config --set auto_activate_base false

一度conda環境を無効化しておきます。

$ conda deactivate

Tensorflowをインストールする環境を作成する

Tensorflowをインストールする環境を作成しましょう。

執筆時点では、TensorFlow 2.8.0が最新なため、これをインストールします。Tensorflow 2.8.0ではPython 3.9に対応しているため、これを使用します。

$ conda create --name tensorflow28 python=3.9

環境名はなんでも構いませんが、ここではtensorflow28としています。

$ conda create --name tensorflow28 python=3.9                                                                                                                                                           
Collecting package metadata (current_repodata.json): done
Solving environment: done

 ・・・

#
# To activate this environment, use
#
#     $ conda activate tensorflow28
#
# To deactivate an active environment, use
#
#     $ conda deactivate

作成した環境を有効化します。

$ conda activate tensorflow28

以下の手順は作成した環境が有効化されていることを前提に進めます。

Tensorflowをインストールする

作成・有効化した環境にTensorflowをインストールします。

Numpy、OpenCV、Matplotlibをインストールする

Tensorflowをインストールする前にNumpy、OpenCV、Matplotlibをインストールしておいた方がよいようなので、先にconda installコマンドでインストールします。

$ conda install numpy opencv matplotlib

Tensorflowをインストールする

Tensorflowを以下の順番でインストールします。

$ conda install -c apple tensorflow-deps
$ python -m pip install tensorflow-macos
$ python -m pip install tensorflow-metal

Tensorflow addonsのビルド・インストールする

Tensorflowの拡張ライブラリであるTensorflow addonsを使用するためには、Apple Siliconではソースコードからビルドしてインストール必要があります（conda install、pip installではうまくいかない）。

ビルドにはbazelが必要なため、まずはこれをインストールします。

$ conda install bazel

次にwheel、setuptoolsが最新でないとビルドに失敗するという報告もあるため、最新化しておきます。

$ python -m pip install --upgrade wheel setuptools

準備が整いましたので、Tensorflow addonsをダウンロードし、ビルドします。

$ git clone https://github.com/tensorflow/addons.git
$ cd addons
$ python ./configure.py
$ bazel build build_pip_pkg
$ bazel-bin/build_pip_pkg artifacts

ビルドが完了すると、artifactsディレクトリの下にファイルが作成されます。

$ ls ./artifacts                                                                                                                                                                                          
tensorflow_addons-0.17.0.dev0-cp39-cp39-macosx_11_0_arm64.whl

作成されていることが確認できましたら、これをインストールします。

$ python -m pip install ./artifacts/tensorflow_addons-0.17.0.dev0-cp39-cp39-macosx_11_0_arm64.whl

これで、TensorflowおよびTensorflow addonsのインストールが完了となります。

参考文献

本手順は以下を参考に作成しました。

M1MAX MacBook Proで深層学習