Chrome 147がDevToolsを大幅改善。コード生成とデバッグ効率が向上

つくば市のホームページ制作会社

4月7日にリリースされたChrome 147では、DevToolsの機能が大幅に強化され、ウェブ制作の作業効率向上に直結する改善が多数盛り込まれている。Chrome 147では自動コンテキスト選択によるAIアシスタンス機能が導入され、「このページで最も遅いネットワークリクエストは何か？」といった開放的な質問に対応できるようになった。

特に注目すべきはChrome 142で導入されたGeminiによるコード提案機能が、Chrome 147では完全なコード生成機能にアップグレードされた点だ。自然言語でのコメント（例：// すべてのimg要素の有効なalt属性をチェックするループ）を書いてCmd+I（Mac）またはCtrl+I（Windows/Linux）を押すだけでコードが生成される。これまでコーディング中の小さなタスクで時間を取られがちだった制作者にとって、作業の流れを維持しながら効率を上げる実用的な機能といえる。

ネットワークパネルでは、gzipやdeflateで圧縮されたHTTPリクエストのペイロード表示が改善され、以前は文字化けしていた圧縮データが自動的にデコードされて読みやすい内容として表示されるようになった。API通信のデバッグやパフォーマンス解析を頻繁に行うウェブ制作者には、地味ながら重要な改善だ。リクエスト一覧にはTransfer Size情報も追加され、通信量の把握がより正確になった。

アクセシビリティ面でも着実な改善が見られる。パフォーマンス指標カードのタイトルヘルプボタンが常時表示されキーボードアクセス可能になり、ホバー時のみの表示から改善された。Lighthouseのカテゴリグループチェックボックスでスクリーンリーダー向けアナウンス機能も向上した。

Chrome 147では技術的な変更も重要だ。Local Network Access（LNA）制限が拡大され、WebSockets接続でローカルアドレスへのアクセス時に権限プロンプトが表示されるようになった。これはサイトがユーザーのローカルネットワークをフィンガープリントに使用する能力を制限し、セキュリティを向上させる目的がある。開発環境でローカルサーバーを多用する制作者は、この変更により一時的な設定調整が必要になる可能性がある。

より大きな視点では、Chrome開発チームは2026年9月8日のChrome 153から2週間リリースサイクルへの移行を発表した。リリースの頻度は上がるものの、変更範囲が小さくなることで混乱は最小限に抑えられ、バグ修正やデバッグも簡素化されるとされている。制作現場では新機能への対応スピードが求められる一方で、個別の変更による影響は軽減される見通しだ。

CSS Anchor Positioningが実用段階へ、JavaScriptライブラリからの卒業が現実的に

つくば市のホームページ制作会社

ツールチップやドロップダウンメニューの位置調整を、Pure CSSだけで実現する時代がついに到来している。2026年1月以降、CSS Anchor Positioningが最新のデバイスとブラウザで動作するようになり、これまでPopper.jsやFloating UIといったJavaScriptライブラリに依存していた制作現場にとって、新しい選択肢が広がっている。

ブラウザサポートが急速に拡大

CSS Anchor Positioningの最大の変化は、ブラウザサポートの進展だ。2025年9月にSafari 26でアンカーポジショニングがリリースされ、主要ブラウザ3社のうち2社がサポートする状況となった。FirefoxについてもNightly版でのテスト進展が印象的で、まもなく到着予定とされている。

これまでJavaScriptで複雑性とパフォーマンス問題を抱えていた実装が、CSS（とHTML）で宣言的に実現できるようになった意味は大きい。特に中小企業のウェブサイトでは、外部ライブラリへの依存を減らしつつ、パフォーマンスを向上させられる可能性がある。

基本的な仕組みと実装方法

CSS Anchor Positioningは、要素同士を紐づけて、アンカー要素のサイズと位置を基準に、アンカー配置要素のサイズと位置を設定できる機能を提供する。

基本的な実装は2ステップだ。まずアンカーとなる要素にanchor-nameプロパティでダッシュ付きの識別子を設定し、次に配置したい要素でposition-anchorプロパティを使ってアンカー名を指定する。

anchor()関数をinsetプロパティ値で使用することで、関連するアンカー要素のエッジ位置を基準とした長さ値を取得できる仕組みになっている。これまでのような座標計算をJavaScriptで行う必要がなくなり、ブラウザが自動的に位置を調整してくれる。

フォールバック機能と実用的な配慮

CSS Anchor Positioningの優れた点は、複数の代替位置をCSS単体で指定できる仕組みを提供していることだ。例えばツールチップがデフォルト位置で画面外にはみ出しそうな場合、ブラウザが自動的に別の提案位置で表示を試すか、必要に応じて完全に隠すかを選択できる。

ただし現在のブラウザ実装には課題もある。SafariとChromeで、配置要素が包含ブロックに対してどう調整されるかの動作が異なっている状況があり、実際のプロジェクトでは動作確認が重要になる。

またポップオーバー要素と組み合わせる場合、position-areaが設定されていればmargin: autoが無効化される仕様変更により、将来的にはより使いやすくなる予定だ。

制作現場での採用判断

実用性の観点では、CSS Anchor Positioningはブラウザネイティブの解決策として、配置要素を純粋なCSSでアンカー要素に紐づけ、スペース不足時の自動フォールバック位置まで対応している点が魅力だ。

ただし導入時期については慎重な判断が必要だろう。現状ではBaselineに近づいているものの、より多くの人々が試用する中で改善点やブラウザ間の違いが発見されている段階だ。特にFirefoxサポートが本格化するまでは、重要なUI要素での採用は段階的に進めるのが現実的かもしれない。

とはいえ長年Popper.jsやFloating UIが浮動要素配置の標準だった状況を考えると、将来的にはCSS Anchor Positioningがこれらの用途の多くを置き換えていく可能性は高い。制作効率とパフォーマンス向上の両面で、この技術の動向は注目しておきたいところだ。

WordPress 6.8で実現するページの先読み技術、Speculation Rules APIの実用性

つくば市のホームページ制作会社

WordPressの最新版6.8「Cecil」では、Speculation Rules APIによる先読み機能がコアに統合されました。この機能により、ユーザーのクリック前にページを先読みすることで、Largest Contentful Paint（LCP）のパフォーマンスが大幅に改善し、設定によってはページの即座読み込みも実現可能となっています。

Speculation Rules APIは、ユーザーの行動を予測してページやリソースを事前に読み込む最適化技術で、JSON形式でルールを定義してブラウザに先読みの指示を出す仕組みです。現在はChrome、Edge、OperaなどのChromium系ブラウザでサポートされており、Safari や Firefox では機能は無視されるものの、悪影響はなく、単に先読みの恩恵を受けられないだけです。

WordPress 6.8では、デフォルトで保守的な設定が採用されており、クエリパラメーターやハッシュフラグメントのないアンカーリンクに対してのみ先読みが適用されます。現時点では先読み（prefetch）モードと保守的（conservative）な積極性が採用されており、ユーザーがリンクと相互作用したときにURLが先読みされる仕組みです。

実際のパフォーマンス向上効果

この機能の効果は実際のサイト運営で確認されています。複数のクライアントサイトでのテストでは、体感的なページ読み込み時間が最大40%短縮された事例も報告されています。ユーザーからの評価では、なぜかは言葉で表現できないものの、先読み機能を有効にしたサイトの体験を好む傾向があり、「サイトがより高級に感じる」という反応も得られているとのことです。

ただし、先読み機能は同一サイト内での別ページへの遷移時にのみ効果を発揮するため、個別のURLに対するベンチマークテストでは効果を測定できず、実際のユーザー体験では測定結果以上の改善効果が期待できます。

WordPress 6.8のコア機能では保守的な先読みのみですが、専用のSpeculative Loadingプラグインを使うことで、より積極的な事前レンダリング機能を利用でき、設定画面から先読みの方式と積極性をカスタマイズすることも可能です。制作現場では、サイトの性質に応じてこれらの設定を調整することで、さらなるパフォーマンス向上が見込めるでしょう。

CSSコンテナクエリがついに実用段階に。レスポンシブの概念が変わる新しいウェブデザイン

つくば市のホームページ制作会社

従来のレスポンシブデザインといえばメディアクエリを使ったビューポート（画面幅）ベースの実装が主流でしたが、2026年現在、CSSコンテナクエリがブラウザサポート95%を超えて実用段階に入り、コンポーネントレベルでのレスポンシブデザインという新しい概念が現場に浸透しています。これまでのような「画面幅が何px以下なら」ではなく、「コンポーネントを囲む親要素の幅が何px以下なら」という条件で、より柔軟で再利用しやすいレスポンシブ要素を作れるようになりました。

コンテナクエリが解決する根本的な問題

メディアクエリの最大の制約は、コンポーネントがどんな文脈で使われるかを知らないことでした。コンポーネントは親コンテナがどのくらいのスペースを持っているかしか知らず、ビューポートのサイズは関係ありません。コンテナクエリは、コンテナのサイズに基づいてスタイルを定義することで、コンポーネントを真に移植可能にします。

たとえば、カードコンポーネントをメインコンテンツエリアで使う場合とサイドバーで使う場合、従来は異なるCSSクラスを作るか、JavaScriptで制御する必要がありました。2026年では、同じCSSクラスのカードコンポーネントが、フルワイドヒーローレイアウトでもサイドバーの小さなサムネイルでも自動的に適応します。

ブラウザサポート状況と実装の現状

サイズコンテナクエリは、Chrome 105+、Firefox 110+、Safari 16+、Edge 105+でサポートされ、2026年時点で95%以上のグローバルカバレッジを実現しています。一方で、スタイルクエリ（@container style()）は、Chrome 111+とEdge 111+のみで、FirefoxとSafariはまだ開発中です。

カスタムプロパティを条件とするコンテナスタイルクエリについては、Firefox側の対応次第で、2026年中には実用的になる見込みが高いとされています。実用性を重視するなら、当面はサイズクエリを中心に実装を進めるのが賢明でしょう。

現場で使えるコンテナクエリの基本実装

コンテナクエリの基本構文は、まず親要素にcontainment contextを設定することから始まります：

`.card-container { container: card / inline-size; }` のようにコンテナタイプを `inline-size` に設定することで、親の横方向（英語のような左から右への言語では幅）をクエリできます。続いて子要素に対して `@container (max-width: 400px) { .card-child { grid-template-columns: 1fr; } }` のように条件付きスタイルを適用します。

2026年時点で、:has()疑似クラスも全主要ブラウザで100%サポートされ、プロダクション環境で安全に使える標準ツールとなりました。これにより、コンテナクエリと組み合わせて、より複雑な条件分岐をCSSだけで実現できます。

メディアクエリからの移行戦略

コンテナクエリは既存のメディアクエリを完全に置き換えるものではありません。ページレベルのレイアウト決定（グリッドカラム、サイドバー表示、ナビゲーションスタイル）にはメディアクエリを使い、コンポーネントレベルのレイアウト決定（カードレイアウト、ウィジェット密度、テキスト折り返し）にはコンテナクエリを使うという使い分けが重要です。

移行は段階的に進めます。複数のレイアウトコンテキストで使われるコンポーネント（カード、ウィジェット、ナビゲーション）を特定し、それらの親ラッパーに `container-type: inline-size` を追加します。各コンポーネントの @media ルールを @container ルールに変換し、ブレイクポイント値を調整します（コンテナ幅はビューポート幅より小さくなるため）。

古いブラウザへの配慮として、@supports (container-type: inline-size) を使ってメディアクエリフォールバックを提供し、@supportsでプログレッシブエンハンスメントを行うことで、古いブラウザでもメディアクエリに適切にフォールバックします。

中小企業のウェブ制作現場では、まず最もよく再利用されるコンポーネントから移行を始め、固定幅コンテキストでのみ使用されるものは後回しにするという現実的なアプローチが効果的です。2026年のモダンCSSは、クライアントサイドJavaScriptなしで、真にモジュラーで弾力性があり、高パフォーマンスなUIを構築できる段階に達しています。

制作者が知っておくべきウェブ技術の新動向を整理してみた

つくば市のホームページ制作会社

春の新しい技術や動向が出揃ってきたので、今知っておきたいウェブ制作・WordPress・セキュリティの動きを整理してみました。それぞれがどう制作現場に影響するか、中小企業サイトでどう活用できるかという視点で見ていきます。

WordPress 7.0の準備が本格化

WordPress 7.0は2026年5月20日にリリース予定で、現在RC（リリース候補版）の最終テストが行われています。リアルタイム共同編集機能がGutenberg Phase 3の一環として導入される見込みで、複数人でのコンテンツ制作が大きく変わりそうです。

ただし、この機能にはWebSocket接続をサポートするホスティングが必要になる可能性があるため、現在のサーバー環境が対応しているかの確認が必要です。システム要件もPHP 7.4以上、MySQL 8.0またはMariaDB 10.6以上に引き上げられるため、古い環境からのアップグレード計画も立てておきたいところです。

WordPress 6.9.1のメンテナンスリリースも2月に配布済みで、49件のバグ修正が含まれています。メジャーバージョンの前に安定性を確保する流れが見えています。

CSS コンテナクエリがようやく実用段階に

コンテナサイズクエリは、Chrome 105+、Firefox 110+、Safari 16+、Edge 105+で95%以上のグローバル対応を達成し、制作現場で本格的に使えるレベルになりました。2015年から求められていた機能が、ついに全主要ブラウザで実際に動作する状況です。

コンテナクエリの何が変わるかというと、コンポーネントがビューポートサイズではなく、親コンテナのサイズに基づいてスタイルを調整できることです。同じカードコンポーネントをサイドバーに配置しても、メディアクエリだとページ幅を見てしまうが、コンテナクエリならサイドバーの幅に応じて適切にレイアウトが変わるというわけです。

ただし、スタイルクエリ（@container style()）はChrome 111+とEdge 111+のみ対応で、FirefoxとSafariはまだ開発中なので、段階的な導入が賢明でしょう。

Core Web VitalsのINPが本格始動

Interaction to Next Paint（INP）は2024年3月にFirst Input Delay（FID）に代わってCore Web Vitalになりましたが、2026年に入ってその影響が本格化しています。

2026年初頭のCrUXデータによると、43%のウェブサイトがINPの200ミリ秒の閾値をクリアできず、最も失敗率の高いCore Web Vitalとなっています。FIDからINPへの移行により、モバイルのCore Web Vitals合格率が約5ポイント低下しており、多くのサイトで対応が急務です。

INPがFIDより厳しいのは、最初のインタラクションだけでなく全てのインタラクションを測定し、入力遅延だけでなく処理時間と描画遅延も含むためです。重いアニメーションや複雑なJavaScriptが動くサイトでは、パフォーマンスの見直しが必要になるでしょう。

WordPressセキュリティの新たな脅威

4月のセキュリティ動向で注目すべきは、Essential Pluginポートフォリオの31個のプラグインで、所有者変更後にバックドアが仕込まれ、8か月間潜伏した後に数千のサイトが感染した事件です。

WordPressはプラグインの所有者変更をユーザーに通知しない仕様のため、信頼していたプラグインが密かに悪意のあるコードを含むようになっても気づけません。最近の1週間だけで185件の新しい脆弱性が発見されており、そのうち16件は未修正という状況も踏まえると、定期的なセキュリティ監査の重要性が高まっています。

2026年には商用WordPressプラグインは法的にEU圏ユーザーに提供するため脆弱性開示プログラム（VDP）の設置が義務化される予定で、セキュリティ体制の透明性がより求められるようになります。

実務への影響を考える

これらの動向を踏まえ、制作現場で今できることを整理すると、WordPress 7.0に向けては現行サーバー環境の要件確認、コンテナクエリは既存メディアクエリとの併用での段階導入、INP対策は重いJavaScriptの見直しとパフォーマンス測定の習慣化、セキュリティは月次でのプラグイン監査の仕組み作りが挙げられます。

3つのCore Web Vitalsすべてをクリアしたサイトは、失敗サイトと比べて離脱率が24%低く、オーガニック検索トラフィックの改善も確認されているという調査結果も出ているため、パフォーマンス改善の投資対効果は明確です。

新技術の導入は一度にすべて対応する必要はありません。現在運用中のサイトの安定性を保ちながら、段階的に新しい手法を取り入れて、ユーザー体験の向上につなげていくのが現実的なアプローチでしょう。

OpenAIが研究者向け生命科学AIモデル「GPT-Rosalind」発表。創薬の10〜15年を短縮するか

つくば市のホームページ制作会社

OpenAIが4月中旬に発表した「GPT-Rosalind」が、生命科学の研究現場で注目を集めています。このAIモデルは生物学、創薬、トランスレーショナル医学に特化して設計されており、「創薬に10〜15年かかる」という医薬品開発の常識を変える可能性があります。

GPT-Rosalindの特徴と性能

GPT-Rosalindは、OpenAIが開発した生命科学専用の推論AIモデルです。従来の汎用AIモデルとは異なり、化学反応メカニズム、タンパク質構造の解析、DNA配列の系統学的解釈といった科学的な推論に最適化されています。

特に興味深いのは、実験結果の解釈と次の実験設計を自動で行える点です。研究者が実験データを入力すると、GPT-Rosalindはそこから専門家レベルのパターンを識別し、外部情報を統合して次の実験プランを提案します。まさに「AI研究助手」として機能するわけです。

製薬業界が注目する理由

アメリカの大手製薬会社アムジェン（Amgen）の上級副社長Sean Bruichは「OpenAIとの独自のコラボレーションにより、最先端の機能とツールを新しく革新的な方法で応用し、患者により早く医薬品を届ける可能性がある」とコメントしています。

現在、新薬の標的発見から規制当局の承認まで平均10〜15年を要していますが、GPT-Rosalindのような専門特化AIが研究プロセスの各段階を効率化することで、この開発期間を大幅に短縮できる可能性があります。

Codex研究プラグインで連携強化

GPT-Rosalindと同時に、OpenAIは「Codex研究プラグイン」も発表しました。これは科学者が50以上のツールとデータソースに接続できるプラグインで、研究ワークフローを大幅に高速化します。

例えば、化合物データベースの検索、分子モデリングツールとの連携、実験結果の可視化まで、一つのインターフェースから様々な専門ツールを使用できるようになります。

Web制作会社の視点から見た意味

RESONIXのようなWeb制作・IT支援会社にとって、このGPT-Rosalindの登場は二つの意味があります。

一つ目は、特化型AIの可能性です。汎用AIが便利なのは確かですが、特定分野に深く特化したAIの方が実用性が高いケースが多くあります。中小企業でも「自社の業務に特化したAI」を検討する価値がありそうです。

二つ目は、API連携の重要性です。GPT-Rosalindのように、AIと既存の専門ツール群を連携させることで、単体では実現できない価値が生まれます。これはWebサイトやシステム開発でも同じことが言えるでしょう。

まだ研究プレビュー段階ですが、GPT-Rosalindが示した「専門特化AI」のアプローチは、他の業界にも応用されていく可能性が高いです。医療・創薬分野での成果に注目ですね。

OpenAIのCodexが「コード書き」卒業。いきなりMacを操作してアプリ間で仕事してしまう

つくば市のホームページ制作会社

4月16日、OpenAIがCodexの大型アップデートを発表しました。今度の更新はタイトルからして遊び心たっぷりで「Codex for (almost) everything」。でも内容は真面目そのもの、開発者の働き方を根本から変えてしまいそうな機能が詰まっています。

いきなりMac画面に現れて作業を代行する

一番驚いたのがバックグラウンドでのコンピュータ操作機能。Codexが自分専用のマウスカーソルを持って、あなたが他のアプリで作業している間に勝手にクリック・タイプして複数のアプリを行き来する。しかも複数のエージェントが並行稼働するから、あなたの作業を邪魔することもない。

これまでのAIコーディングツールって「コード補完がうまい」「バグ修正が得意」みたいな局所的な手伝いだったじゃないですか。でもCodexは違う方向に進んでいる。開発者が日常的にやっている「ブラウザでドキュメント調べて、スクリーンショット撮って、別のアプリに貼り付けて…」みたいな面倒な流れ作業を、丸ごと自動化してくれる方向に向かってる。

「コード生成ツール」から「開発環境そのもの」に

OpenAIは明らかにCodexのポジションを変えにきました。プレスリリースを読んでいて気づいたのは、もう「コードを書くための補助ツール」じゃなくて「開発作業が起きる場所」になろうとしてること。

実際、既存ユーザーの50%がコーディング以外のタスクにCodexを使っていたという数字も発表されてます。だったら最初から全部対応してしまえ、というのがOpenAIの判断みたい。

新機能の一覧を見ると、その狙いがよく分かります：

  • ウェブブラウザをアプリ内に統合（プロトタイピング→コメント→修正のサイクルを高速化）
  • 画像生成機能の追加
  • 過去の操作を学習して記憶する機能
  • SSH経由でリモート開発環境への接続
  • GitHub のPR レビュー機能強化
  • 90以上の新しいプラグイン

これ全部、「開発者の一日の流れ」に沿って設計されてる。朝イチでPRをチェックして、ブラウザで仕様を確認して、リモート環境で作業して、テストして、また別のツールに移る…みたいな。

現場で使うなら「権限管理」が最重要

ここまで強力になると、セキュリティ面の配慮は必須です。RESONIXでクライアントのシステム構築をやってきた経験から言うと、AI エージェントに何でもやらせるのは危険すぎる。

記事によると、最低権限の原則で運用して、必要最小限のアクセス権だけ与えるのが鉄則。それと、AIが何を変更したか必ずログを残すこと。「便利だから」で野放しにすると、後で取り返しのつかないことになりかねません。

特に中小企業の現場では、「人手が足りないからAIにお任せ」という発想になりがちですが、むしろ最初は限定的な範囲で試運転して、徐々に範囲を広げるアプローチが安全でしょう。

競争の軸が「モデルの賢さ」から「統合の滑らかさ」へ

今回のアップデートで面白いのは、OpenAIがAI開発ツールの競争軸を変えようとしてることです。もう「どのモデルが一番賢いか」じゃなくて「どの環境が一番ストレスなく作業を続けられるか」で勝負しようとしている。

これは正しい戦略だと思います。実際の開発現場で本当に辛いのって、コード自体を書くことじゃなくて、その前後の雑多な作業なんですよね。イシューを読んで、仕様を確認して、環境を準備して、テストして、レビューして…。

Codexがその全工程をシームレスに繋げてくれるなら、開発者の生産性は確実に上がるはず。ただし、うまく使いこなせるかどうかは導入する会社次第。整理されたワークフローを持っている組織ほど効果が大きく、逆にぐちゃぐちゃな環境だとAIも混乱してしまう可能性が高いです。

月額500ドルという価格設定も、個人開発者ではなく組織での導入を想定した本気度の表れでしょう。これから半年くらいで、開発チームの働き方が大きく変わってきそうな予感がします。

GoogleのGemini CLI登場で開発者の「面倒」が一気に解決。オープンソースでしかも日本語対応

つくば市のホームページ制作会社

4月に入って、GoogleがGitHubに投入したオープンソースのターミナルエージェント「Gemini CLI」が開発者コミュニティで話題になっています。Apache 2.0ライセンスで公開されたこのツールは、ちょっと面白い立ち位置にあるんですよ。

従来のCLIツールとは全く違うもの

これまでのCLIツールって、コマンドを覚えて、オプションを覚えて、ドキュメントを読んで…という手順でした。でもGemini CLIは、まるで同僚と話すように自然言語で「このディレクトリをクリーンアップして」「テストが通らない理由を調べて」みたいに話しかけることができます。

技術的に見ると、ReAct（Reasoning and Acting）ループという仕組みで動いていて、100万トークンという大きなコンテキストを持っているため、プロジェクト全体を把握しながら作業できるのが特徴です。MCPサポートも組み込まれているので、既存のツールチェーンとも連携しやすくなっています。

面白いのは「日本語対応」の部分

実際に試してみると、日本語のプロンプトでもきちんと理解してくれます。「このバグを直して」「コードレビューして」といった日本語指示に対して、適切にファイルを読み取って、分析して、修正案を提示してくれます。

これって意外と重要で、英語圏のオープンソースプロジェクトは日本語対応が後回しになることが多いのですが、Googleの自然言語処理の強みがここで活きているんじゃないかなと思います。

GitHub Trending上位に食い込んだ理由

4月第3週のGitHub Trendingを見ると、oh-my-codex（OMX）やHermes Agentといったプロジェクトと並んで上位にランクインしています。開発者が注目している理由は、やっぱり「無料でこのレベル」という点でしょう。

AnthropicのClaude CodeやOpenAIのCodex CLIは確かに優秀ですが、API費用がかかります。Gemini CLIは完全にローカルで動くわけではないものの、Googleの太っ腹な無料枠の中で使えるので、個人開発者や小規模チームには魅力的です。

中小企業の開発現場で使ってみたくなる理由

RESONIXでも実際に試してみましたが、これは現場で本当に役立ちそうです。特に新人エンジニアの教育や、既存コードベースの理解を深めたい時に威力を発揮します。

従来だと「このエラーは何が原因？」と聞かれても、先輩エンジニアが手を止めて説明する必要がありました。でもGemini CLIがあれば、「なぜこのエラーが起きているのか調べて、解決策を3つ提示して」みたいに指示すると、コードを読み込んで分析結果を出してくれます。

「Apache 2.0」が持つ意味

オープンソースライセンスの中でもApache 2.0は商用利用に寛容で、企業が安心して導入できます。Googleがこのライセンスを選んだということは、企業での利用を明確に意図しているということ。

実際、開発者向けツールの競争が激化する中で、Googleは「オープンソースで勝負」という戦略を取ったのが面白いです。MicrosoftのCopilot、AnthropicのClaude、OpenAIのCodexがAPI型サービスで課金している中、完全にオープンな戦略で差別化を図っています。

新しいツールが出るたびに「また覚えることが増えた…」と思いがちですが、Gemini CLIは逆に「覚えることを減らしてくれる」タイプのツールです。気になった方は、GitHubからクローンして試してみてください。導入も簡単で、5分もあれば動かせますよ。

AnthropicがClaude Opus 4.7でソフトウェアエンジニアリング界を「一変」させた理由

つくば市のホームページ制作会社

Claude Opus 4.7が4月17日にリリースされ、早速ソフトウェアエンジニアリングの現場でとんでもない反響を呼んでいます。「最も難しいコーディング作業を、もう監視する必要なく任せられるレベル」とユーザーが興奮する理由を探ってみました。

「監視不要」まで到達した理由

Opus 4.7の最大の進歩は、ソフトウェアエンジニアリング能力の大幅改善です。特に最も困難なタスクで顕著な向上を見せており、開発者たちが口を揃えて「これまで密な監視が必要だった最難関のコーディング作業を、Opus 4.7には自信を持って任せられる」と評価しています。

何がそれを可能にしたか。複雑で長時間かかるタスクを厳密性と一貫性をもって処理し、指示に正確に注意を払い、さらに自分の出力を検証する方法まで編み出してから報告するのです。つまり、「自己チェック機能」を持ったAIエンジニアが誕生したといえます。

画像解析も大幅パワーアップ

コーディングだけじゃありません。Opus 4.7は視覚能力も大きく向上し、画像をより高解像度で認識できるようになりました。インターフェース、プレゼンテーション、ドキュメントの作成においても、より洗練されて創造的な成果を生み出すといいます。

これってどういうことかというと、WebデザインからUI/UXデザイン、さらにはプレゼン資料作成まで、「見た目」が重要な業務でもClaudeが頼りになるパートナーになったということ。デザインセンスも備えたAIエンジニア、って感じですね。

新しい制御機能が実用性を加速

Opus 4.7では「xhigh」という新しい労力レベルが追加され、「high」と「max」の中間に位置づけられました。開発者は/effortコマンドや--effort、モデルピッカーから選択でき、他のモデルでは自動的に「high」にフォールバックします。

さらに、Claude Codeでは自動モードがMaxサブスクライバー向けに提供開始。/ultrareviewコマンドなど新しいコントロールも追加され、開発ワークフローがより柔軟になりました。

RESONIXから見た実務への影響

長年Web制作の現場で様々なプロジェクトを手がけてきた立場から言うと、「自己検証するAI」の登場は本当に大きな変化です。これまでAIが生成したコードは必ず人間がレビューする前提でしたが、Opus 4.7レベルなら「最初から品質の高いコードを期待できる」という段階に入りました。

特に中小企業のWebサイト制作やシステム開発において、限られたリソースでより高品質な成果を出す強力な武器になりそうです。ただし、完全に任せきりにするのではなく、「信頼できるパートナー」として活用するのがポイントでしょう。

開発現場の「当たり前」が変わる

週に300万人以上の開発者が使用するClaude Codeの大規模アップデートと合わせて考えると、2026年は「AIとペアプログラミングが当然」の時代になりそうです。リモート開発環境への接続、複数ファイルとターミナルの表示、インアプリブラウザなど、開発者が欲しかった機能が一気に充実しました。

面白いのは、最初に「危険すぎて公開できない」として話題になったClaude Mythosとは対照的に、Opus 4.7は実用的な改善に焦点を当てていること。Anthropicは攻撃的な技術力アピールよりも、開発者の日常業務を確実に改善する方向に舵を切ったように見えます。

この流れを見ていると、2026年後半にはAIを使わない開発現場の方が少数派になるかもしれませんね。技術の進歩を追いかけるだけでなく、どう現場に取り入れるかが重要になってきました。

OpenAIのAgents SDKが本格始動。サンドボックス機能で開発者の「怖い」を一掃してしまった

つくば市のホームページ制作会社

OpenAIが開発者向けのAgents SDKを大幅アップデートしました。今回の更新で最も注目すべきは、AIエージェントを安全に動作させるサンドボックス機能の実装です。これまで「AIに勝手にファイルを触られるのが怖い」「コードを実行させるのは危険」と感じていた開発者にとって、まさに待ち望んでいた機能と言えるでしょう。

安全性の不安を解消するサンドボックス実行

従来のAIエージェント開発では、モデルがファイルシステムに直接アクセスしたり、予期しないコマンドを実行する可能性がありました。今回のアップデートでは、エージェントを制御された環境内で動作させるサンドボックス機能が追加され、この問題が根本的に解決されています。

具体的には、エージェントがファイルの検査、コマンドの実行、コード編集を行う際も、すべて隔離された安全な環境内で処理されます。開発者は自前のサンドボックスを使うこともできますし、Blaxel、Cloudflare、Daytona、E2B、Modal、Runloop、Vercelなどの組み込みサポートから選択することも可能です。

企業利用を想定したハーネス機能の強化

もう一つの大きな改良点は「ハーネス機能」の拡張です。これはエージェントがモデル以外の要素とやり取りするための仕組みで、今回のアップデートで大幅に強化されています。

新しいハーネスには設定可能なメモリ機能、ファイルシステムツール、標準化された統合機能が含まれており、エージェントがドキュメントやシステムとより効果的にやり取りできるようになりました。RESONIXでも企業のワークフロー自動化を手がけることがありますが、こうした機能があれば社内のファイル操作や承認フローと連携したエージェントが作りやすくなりそうです。

特に注目したいのは「Manifest抽象化」という機能。これによってエージェントのワークスペースを標準化された形で記述でき、ローカルファイルのマウントや出力ディレクトリの定義、AWS S3やGoogle Cloud Storageといったクラウドストレージとの接続が簡単になります。

実際の企業事例から見える実用性

既にいくつかの企業が新しいAgents SDKを実際に活用しています。法務システムを手がけるLexisNexisは「複雑な法務文書の作成ワークフローが統一されたフレームワークで実現できるようになった」とコメント。また、Coinbaseは数時間でAI エージェントと暗号通貨ウォレットを連携させるAgentKitを完成させています。

Oscar Healthというヘルスケア企業の事例も興味深く、複雑な医療記録から正確なメタデータを抽出するワークフローを自動化したとのこと。これまでの手法では信頼性に欠けていた処理が、新しいインフラで確実に動作するようになったそうです。

中小企業の現場でも、顧客サポートの自動化や複数段階にわたる調査作業、コンテンツ生成などに応用できそうな事例ばかりです。

開発者にとって何が変わるのか

今回のアップデートで開発者の作業が大幅に簡略化されます。これまでエージェント開発では「プロトタイプは作れるけど、本格運用は不安」という声をよく聞いていました。セキュリティ面や統合の複雑さが障壁になっていたんですね。

新しいSDKではこうした課題が解決され、開発者は独自のビジネスロジックに集中できるようになります。標準化されたプリミティブ（Tool use、カスタム指示、ファイル編集など）が用意されているため、基盤部分を一から構築する必要がありません。

現時点ではPythonでの提供ですが、TypeScriptサポートも計画されており、コードモードやサブエージェントといった更なる機能拡張も予定されています。料金は標準APIの価格体系に基づいており、特別な契約は不要です。

AIエージェントの実用化がいよいよ現実的になってきました。安全性の担保された環境で、企業レベルのワークフローを自動化できるツールが手に入ったわけですから、これは開発者にとって大きなターニングポイントになりそうです。