何が変わったか

フォアグラウンドセッションでも ← 1回でAgents Viewに移動できるようになりました。

リリースノートにはこう書いてあります：

Changed opening the agents view from a foreground session to require a single ← press instead of two, matching the behavior in background sessions

以前はフォアグラウンドセッション（通常の作業中の画面）から Agents View を開くには、← キーを 2回 押す必要がありました。バックグラウンドセッションでは1回で開けていたのに、フォアグラウンドだけ2回必要という微妙な非一貫性があったわけです。

今回の変更でフォアグラウンドも1回に統一されました。

Agents View って何？

Claude Code には複数のエージェント（サブタスク）を並列で動かす機能があります。Agents View はその実行中エージェントの状態を一覧で確認できる画面です。

┌─ Agents ─────────────────────────────────────────────────────┐
│ ● agent-1  Running  「APIエンドポイントの調査中...」          │
│ ● agent-2  Running  「テストコードのレビュー中...」           │
│ ✓ agent-3  Done     「ドキュメント生成完了」                  │
└──────────────────────────────────────────────────────────────┘

複数のエージェントを走らせているとき、Agents View を素早く確認できるかどうかはワークフローの快適さに直結します。

実際の使い勝手

弊社では複数プロジェクトを並行開発することがよくあります。特に便利なのが以下のようなフローです。

1. 「このコードをレビューして」と Claude Code に依頼する
2. レビュー用のサブエージェントが起動する
3. そのサブエージェントにカーソルを合わせた状態で ← を押す
4. Agents View にそのエージェントが追加され、進捗をいつでも確認できる

サブエージェントが動いている間も自分は別の作業を続けられますし、Agents View を ← 1回でサッと開いて状態確認できるので、思考の流れを途切れさせずに作業を進められます。

弊社では現在、レビューエージェントの起動は手動で行っています。これはレビュースキルやモデルを使い分けたいためで、状況に応じて意図的に選んで起動しています（エージェント選定も含めて自動化するフルオートモードも搭載しています）。それでも「依頼→サブエージェント起動→←でフォーカス→Agents Viewで追跡」という流れが定着すると、複数エージェントを走らせているときの確認作業がかなりスムーズになります。

また、Agents View 内での操作もシームレスです。↑↓キーでメインエージェントとサブエージェントを行き来して、←キーでAgents Viewに戻り、別のタスクに移動——この一連の操作がキーボードだけで完結するのがとても気持ちいいです。ウィンドウを切り替えたりタブを探したりすることなく、作業の流れを完全に維持したまま複数タスクを管理できます。

これまでは Agents View を開くたびに ←← と2回打つ必要があり、「あ、そうだった」と毎回思い出す小さなストレスがありました。1回になるだけで体感が変わりますね！

余談：以前から使えた隠し機能だった

実は、Claude Code にこの機能が存在することを知らなかった方も多いのではないでしょうか。← キーでAgents Viewに行けること自体、リリースノートを追っていないと気づきにくい機能です。

「最初から2回押しで使えたのに気づいてなかった」という方も多いかもしれません（筆者もそのひとりです）。

こういう細かい UX 改善が積み重なって、ツールの使いやすさは少しずつ上がっていくものですね。Claude Code は更新頻度が高く、毎週のように改善が入ってくるので、定期的にリリースノートを眺める習慣をつけておくと発見があります。

おわりに

AIツールを使った過去資産のリニューアルや、自社の開発プロセスにAIを組み込みたいとお考えの方は、ぜひ弊社にお声がけください。FITSは仙台を拠点に大規模なAI駆動開発を手がけており、要件定義から実装・運用まで一貫してサポートいたします。

お問い合わせは FITSお問い合わせページ からお気軽にどうぞ。

参考
– Claude Code v2.1.196 リリースノート（GitHub）

起動したら見慣れないメッセージが

Claude Code を起動したら、いつもと違う案内が表示された。

✔ Using flicker-free rendering · if you want to go back, use /tui default
    · Click to move your cursor in the text input
    · Click to expand collapsed tool results
    · By default, text auto-copies when you select it (/config to change)
    · Hold Fn while selecting to use your terminal's native copy instead

「お、なんか新しくなってる」と思って調べてみたら、ターミナルの描画方式が刷新されたお知らせだった。気づかないうちにどんどん便利になっていく。

今回有効になったもの：ちらつきのない新描画モード（flicker-free / NO_FLICKER）

新しい描画エンジン（experimental renderer）が有効になったという通知。Anthropic が「NO_FLICKER モード」として発表していたもので、2026年4月に Product Hunt にも登場して話題になっていたらしい。

そういえばうちのメンバーが以前 Slack に「Agent View の画面めっちゃ点滅するから Claude に相談したら『持病みたいなもんです』って言われた　草」と投稿していた。あれはこのことだったのかも。当の Claude も認めていたとは。

何が変わった？

• 画面のちらつき（フリッカー）がなくなった … 出力が更新されるたびに画面全体がチカッと白く再描画される現象が解消
• マウス操作に対応
  • 入力欄をクリックするとカーソルがその位置に移動（矢印キー連打から解放）
  • 折りたたまれたツール実行結果をクリックで展開
  • ホイールでスクロール、URL を直接クリック
• 入力欄が常に画面下部に固定 … どれだけ出力が流れても入力位置が動かない
• 長時間セッションでもメモリ使用量がフラット … 画面に見えている範囲だけ描画する仕組み（Vim や htop と同じ発想で、表示制御をアプリ側に持ってきた）

ちょっとした操作メモ

• テキストは選択するだけで自動コピーされる（/config で変更可能）
• ターミナル本来のコピーを使いたいときは Fn を押しながら選択
• 元の描画方式に戻したいときは /tui default

感想：地味だけど毎日触る部分が快適になるのは一番効く。ちらつきが消えるだけでこんなに見やすいとは。

v2.1.193（2026年6月25日）で増えた機能

調べたら、ちょうど直近の v2.1.193 でもいろいろ追加されていた。

• bash モード（!）でファイルパスのライブ補完 が効くようになった ← これ地味に嬉しい
• MCP サーバーの認証案内 … 認証が必要なときに /mcp を案内してくれる
• Auto モードの拒否理由を表示 … なぜブロックされたかが transcript / トースト / /permissions で見えるように
• autoMode.classifyAllShell … すべての Bash/PowerShell コマンドを auto-mode の分類器に通す設定
• アイドル状態のバックグラウンドシェルを自動でメモリ回収
• バックグラウンドエージェントが別タスクを進めながら動けるよう改善

このあたりの最近のバージョンも合わせて面白かったもの

• /rewind コマンド（v2.1.191） … /clear する前の会話を復元できる。やらかしたときの保険になる
• ストリーミング中の CPU 使用率を約37%削減（v2.1.191） … 体感の軽さに効いてそう
• フルスクリーンモードのメニューでマウスクリック対応（v2.1.187） … 今回の描画刷新と地続き
• Auto モードの安全強化（v2.1.183〜） … git reset --hard や terraform destroy など破壊的コマンドを明示指示なしではブロック

X などで話題になっていた「これ気になる」機能

最近の Claude Code 周りで盛り上がっていた、個人的に試してみたい機能たち。

1. Agent Teams（エージェント・チームズ）

複数の Claude Code が並列で作業して大きなタスクを分担。2026年4月に Claude Opus 4.6 とともにリサーチプレビューとして登場（本記事執筆時点でもリサーチプレビュー）。各エージェントがそれぞれ独立した最大100万トークンのコンテキストを持つ。
→ 使ってみた： すでに使っています。ワクワクしますね。大きめのリファクタや調査を「手分け」してもらえて便利です。ただ Windows 版は Mac 版と機能差異があるようで、Windows ユーザーには少し使いづらそうでした。

2. Remote Control（リモートコントロール）

ローカルで動いている Claude Code のセッションを、スマホ（iOS/Android の Claude アプリ）やブラウザから遠隔操作できる（2026年2月リサーチプレビュー）。
→ 現状 OFF： ガバナンス上いったん OFF にしています。確認が取れたら ON にしたい機能です。

3. 音声モード（/voice）

2026年3月追加、20言語対応。
→ 個人的な感想： Mac の音声入力を日頃から使っているので、「あまり不便を感じていなかった」というのが正直なところ。ただ、ひとつ気になっていたのが「Claude 側はコンテキストを反映して音声認識してくれるのか？」という点。調べてみたら、そうでした。公式ドキュメントによると「現在のプロジェクト名と git ブランチ名が認識ヒントとして自動で追加される」とのこと。コーディング語彙（regex、OAuth、JSON、localhost など）の認識精度もチューニング済みで、Mac の音声入力と使い分ける価値は十分ありそうです。

4. レート制限の緩和

2026年5月、5時間レート制限が2倍に。Pro/Max のピークタイム制限も撤廃。
→ これは話題というより素直にありがたいニュース。長時間エージェント運用が現実的に。

まとめ

起動時のメッセージひとつ取っても、裏ではこまめに改善が積み重なっているのが分かる。ちらつき解消みたいな「触り心地」の改善から、Agent Teams みたいな働き方そのものを変える機能まで、振れ幅が広い。

気づいたら便利になっている。アップデートを追いかけるだけでも楽しいですね。これからも頻繁にチェックしようと思います。

参考リンク

• Claude Code changelog（公式）
• Fullscreen rendering – Claude Code Docs
• Claude Code Rendering（Product Hunt）

弊社では業務のさまざまな場面でAIを活用しています。今回は、会社のブログサーバーの引っ越し作業を、AIエージェント（Claude Code）と一緒にやってみた話をご紹介します。しかもネコちゃんが作業してくれます。

きっかけ：ブログのサーバーを新しくしたい

弊社のブログは、AWSのLightsailというサービスの上でWordPressを動かして運用しています。

このブログサーバー、もともと一番小さいプラン（メモリ0.5GB）で動かしていたのですが、WordPressを快適に動かすにはちょっと力不足。さらに、サーバーに入っているソフトウェア（データベースやWebサーバー）のバージョンが古くなってきていました。

そこで、新しいサーバーを立てて、データを引っ越そうということに。ついでにメモリも倍増させます。

月額たった$2アップで、メモリもディスクも倍。ソフトウェアも全部最新。やらない理由がありません。

でも、サーバーの引っ越しってめんどくさい

サーバーの引っ越しって、地味に手順が多いんです。

1. 新しいサーバーを作る
2. セキュリティの設定をする
3. 旧サーバーからデータベースやファイルをコピーする
4. 新サーバーに取り込む
5. ちゃんと動くか確認する
6. ネットワークの向き先を切り替える
7. SSL証明書（httpsの鍵）を設定する
8. 後片付けをする

手作業でやると、どこかで打ち間違えたり、手順を飛ばしたりしがち。そこで……

AIに全部やらせよう

Claude Code（Anthropic社が提供するAIエージェント）は、ターミナル（黒い画面）で動くAIです。人間がキーボードで打つコマンドを、AIが代わりに実行してくれます。

つまり、サーバーにSSH接続してコマンドを打つ作業も、AIにお任せできるわけです。

やったこと

Claude Codeに「ブログサーバーを新しいインスタンスに移行して」と伝えたところ、こんな流れで進みました。

1. 計画を立てる — AIが移行手順を10ステップで提案（数秒）
2. 移行スクリプトを作る — AIが約330行のシェルスクリプトを自動生成（数十秒）
3. 人間がレビューする — 内容を確認してバグを1件発見・修正（数分）
4. 実行する — スクリプトを実行して、AIが全工程を自動で処理

計画もスクリプト作成も一瞬。人間がやるのはレビュー（確認）だけです。

レビューで見つけたバグ

AIが作ったスクリプト、ほぼ完璧だったのですが、1つだけバグがありました。

サーバーの引っ越しでは、途中でネットワークのアドレスを旧サーバーから新サーバーに付け替えます。AIはこの「付け替えた後も、古いアドレスに接続しようとしていた」んです。

住所が変わったのに、前の住所に手紙を送っちゃうようなもの。これは人間がレビューして発見・修正しました。

ちなみに、今のAIはプロンプト（指示）や用途を適切に設計すれば、レビュー作業もAIに任せることができます。今回はあえて人間がレビューしましたが、次回は「レビュー担当AI」を用意するのもアリですね。

作業ネコちゃんと監督ネコちゃん

せっかくなので、実行も少し楽しくしました。

画面を上下に2分割して、「作業ネコちゃん」（作業する側）と「監督ネコちゃん」（チェックする側）の2匹のAIエージェントに役割を分けて実行させました。

監督ネコちゃんは、作業ネコちゃんから報告を受けるたびに内容をチェックして、問題なければ「ヨシッ！」と承認します。特に重要な工程（ネットワーク切り替えなど）では、監督ネコちゃんの承認がないと先に進めない仕組みです。

監督ネコちゃん

── 監督ネコちゃん ──

作業ネコちゃんからの報告を確認中…

 

【フェーズ6: 動作確認（仮IP）】

WordPress管理画面… OK

ブログ表示… OK

データベース… OK

監督ネコちゃん「ヨシッ！動作確認OKニャ！」

 

【フェーズ7: ネットワーク切り替え】— 重要工程

この工程は監督ネコちゃんの承認が必要です

旧サーバーからIPアドレスを切り離し…

新サーバーにIPアドレスを割り当て…

監督ネコちゃん「ヨシッ！切り替えてOKニャ！」

── 作業ネコちゃん ──

【フェーズ7: ネットワーク切り替え】 実行中…

監督ネコちゃんの承認を確認… 承認済み

IPアドレス切り替え中…

ネットワーク切り替え完了！

監督ネコちゃんが「ヨシッ！」で承認。ネットワーク切り替えという重要な工程も安心です。

移行完了！

── 監督ネコちゃん ──

[進捗: 10/10 フェーズ完了]

 

全フェーズ完了！ヨシッ！！！

作業ネコちゃんお疲れさまニャ！

ブログ記事も書くニャよ！

 

監督業務完了ニャ

── 作業ネコちゃん ──

フェーズ10: 後片付け… 完了

 

移行完了ニャーーー！！！

 

====================================

全10フェーズ正常完了

ブログURL: https://blog.fits-inc.jp

====================================

全工程完了！監督ネコちゃん「ヨシッ！！！」作業ネコちゃん「移行完了ニャーーー！！！」

実際の作業はすべてAIが自動で行っています。人間はターミナルを眺めているだけ。ネコちゃんたちが頑張ってくれました。

移行結果

無事、ブログの引っ越しが完了しました。

サーバーの中身はすべて最新になり、メモリにも余裕ができました。ブログの表示速度も体感で速くなっています。

AIにインフラ作業を任せてみて

今回の移行を通じて感じたのは、AIは「速くて正確な作業員」として非常に優秀だということです。

• 計画立案：移行手順の洗い出しが数秒で完了
• スクリプト生成：330行の移行スクリプトが数十秒で完成
• 実行：10ステップの作業を自動で正確に実行
• チェック体制：監督ネコちゃん＋作業ネコちゃんの2体制で安全に運用

今回は人間がスクリプトをレビューしてバグを1件見つけましたが、実はこのレビュー作業もAIに任せることができます。プロンプト（指示）や用途を適切に設計すれば、AIが計画・実行・チェックまで一貫して担える時代になっています。

もちろん、お客様の大事なシステムをお預かりする以上、最終的な判断と責任は人間が持ちます。大事なのは、「AIにどこまで任せて、どこで人間が判断するか」を正しく設計すること。AIの得意・不得意を把握した上で、適切に使い分けることが重要です。

まとめ

弊社FITSは仙台を拠点に、こうしたAI活用を日常の業務に取り入れながら、Webシステムの開発・運用を行っています。

「AIってどう使うの？」「自社の業務にも使えるの？」といったご相談も大歓迎です。仙台でAIを使っていろいろやっている会社として、お気軽にお声がけください。

この記事の執筆・移行作業は、Claude Code（Anthropic）を活用して実施しました。ネコちゃんたちもお疲れさまでした。

場所はJAビルの地下です。JAビルはオフィスのある南町通りからは遠いので、自転車で行く感じですね。表には写真みたいに看板しか出てないのですが、JAビルの横の階段を下がっていくと・・

ご覧のように地下への入り口が現れ、入り口進んで真ん中ほどにお店があります。「寿司」「天ぷら」「極上麦酒」ののれんがかっこいいですね！（天ぷらののれんは畳まれてますが）なお入り口は手動ドアなので、手をかけてぐっと開きましょう

外の壁にもメニューがあります。どうやらお目当ての天丼は400円プラスすると、極上天丼（エビが4本プラス）になるみたいです。

着丼！

アップも。ボリュームたっぷりです。

えび2本、ピーマン、なす、さつまいも、蓮根、ちくわ、しめじ（舞茸じゃなくてしめじなの珍しいですね）などが載っていて、大満足の味でした！なお、タレは衣に絡ませてあるので、どこを食べてもタレの味がして美味しい！以前に、アーケードの天丼てんやがなくなって、仙台で天丼が食べたくなったらどこ行けばいいんやーって悲しい気持ちになったのですが、これからはさかえさんに行こうと思います。なお、店長さんのお名前がさかえさんなので、お店のなまえもそこから取ったんだろうなーって思ってます。

あと、帰り道で知ったのですが勾当台公園に地下道を通す工事をやっているみたいですね。どこまで伸びるか分からないですがフェスやイベントの際に、東と西が行き来しやすくなる配置だといいですね。

店名：寿司・天ぷら・極上麦酒さかえ
場所：JAビル宮城の地下１階
訪問日：10/21（月）
頼んだもの：天丼大盛り1200円
定休日：日曜日

最初に契約した時に手違いがあったのか、必要なチュートリアル資料などが送られてきておらず、公式のチュートリアルアプリを色々と確認しながら少しずつ機能の理解を深めていきました。その中で一番理解が難しかったのがフォーム機能に内包されている「外部API連携」です。

この外部API連携については全然情報が出て来ず、こちらで想定するSlack連携などを組み込んでも全く動作してくれませんでした。設定としては

・会員登録APIのエンドポイント（プレビューアプリ用）
・会員登録APIのエンドポイント（本番アプリ用）
・APIのリクエストパラメータへのマッピング

が存在するようです。試しに設定したエンドポイントに送られてくるデータをネットワークのログで確認したところ

parameters[ud_id]=xxx&parameters[created_at]=2024-06-21 07:27:36&parameters[param1]=yyy&parameters[param2]=zzz

というように、設定したパラメータが parameters[パラメータ名] =バリューのペアで入ったテキストを、URLエンコードしたものが入っているようでした。ただ、郵便番号や性別、生年月日などは含まれておりません（おそらくYappliのサーバーにだけ連携されているのかと）

最終的にどのように利用すればいいのかをサポートに確認したところ、Yappli Lite では外部API連携の設定はできるのだけど、プランの機能には含まれていない、とのことでした。Yappli が機能追加ごとの課金であることは知っていましたが、必要最低限のYappli LiteプランではAPI連携系の機能は一切使えない、とのことでした。Yappli Liteを使ってAPIサーバーとの連携を使ったアプリを作りたい、という場合は注意が必要そうです。

% php -v
dyld[84774]: Library not loaded: @loader_path/../../../../opt/icu4c/lib/libicuio.73.dylib
Referenced from: <90055B36-6315-3FD7-9F54-5F9D08D9F325> /opt/homebrew/Cellar/php@8.0/8.0.30/bin/php
Reason: tried: '/opt/homebrew/Cellar/php@8.0/8.0.30/bin/../../../../opt/icu4c/lib/libicuio.73.dylib' (no such file), '/usr/local/lib/libicuio.73.dylib' (no such file), '/usr/lib/libicuio.73.dylib' (no such file, not in dyld cache)
zsh: abort php -v

brew info で調べてみるとicu4cの74が入っていたようなので、Qiitaや他のテックサイトを参考に、gitからicu4cの73をbrew tapしてインストールする方法を試していたのですが、gitリポジトリでgit clone する際にicu4cのログがgit logで見つからず（おそらくパスが間違っていたのだと思うのですが）、最終的に下記の方法でlibicu4cの7.3をインストールしました。

wget https://raw.githubusercontent.com/Homebrew/homebrew-core/6aca0f221ee4ac0c25735dbf31cc01fed984d8f6/Formula/icu4c.rb
brew reinstall --formula icu4c.rb

最終的にはphp8.0をバージョンアップすることで恒久対応を行ったのですが、取り急ぎphp8.0を使わなくてはいけない方でlibicu4cがバージョンアップされてしまって困っている方がいたら上記の方法で解決できる可能性があります。

まず、PHPのバージョンアップを行う必要性についてですが、PHPのバージョンを更新せずにWordPress を運用していると、ダッシュボードに「PHPの更新を推奨」というメッセージが表示されることがあります。PHPにもバージョンごとにサポート期間が設定されていますので、それが切れるとWordPress側で親切にも警告を表示してくれる、ということですね。

この「PHPの更新についてさらに詳しく」を見るとわかるのですが、WordPress自体にはPHPのバージョンアップをサポートする機能はなく、単純にバックアップを取った後に自身でPHPをバージョンアップさせることとなります。

ただ、過去の経験からLightsailにおけるPHPのアップデート作業は依存関係などで作業が複雑化することが多く、単純にLightsailに別なWordPressインスタンスを構築し、そこに対してバックアップデータを復帰するのが最も確実な対応方法となります。まずはLightsailのダッシュボードから新しいインスタンスを立ち上げていきます。その際に、WordPress用インスタンスイメージを選びましょう。また、立ち上げたら静的IPアドレスをアタッチしておくと良いです。

立ち上げインスタンスを確認すると、PHPのバージョンが新しくなっていることが分かります。※PHPのバージョンはbitnamiのWordPressイメージ次第のため、新しくはあるものの、最新のPHPバージョンではないことに注意してください。

bitnami@ip-xxx-xxx-xxx-xxx:~$ php -v
PHP 8.2.19 (cli) (built: May 7 2024 15:22:14) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.19, Copyright (c) Zend Technologies
with Zend OPcache v8.2.19, Copyright (c), by Zend Technologies
bitnami@ip-xxx-xxx-xxx-xxx:~$

さらに、WordPressの認証情報を確認し、管理画面にもログイン可能であることを確認します。

今回の環境ではWordPressのファイル群は /opt/bitnami/apps/wordpressにまとまっていました。wp-content の中に以降に必要となる uploads、themes、pluginsなども存在しています

root@ip-xx-xx-xx-xx:/opt/bitnami/apps/wordpress/htdocs# ls
activate.html wp-activate.php wp-content wp-mail.php
index.php wp-admin wp-cron.php wp-settings.php
license.txt wp-blog-header.php wp-includes wp-signup.php
pairing.html wp-comments-post.php wp-links-opml.php wp-trackback.php
readme.html wp-config.php wp-load.php xmlrpc.php
robots.txt wp-config-sample.php wp-login.php

root@ip-xx-xx-xx-xx:/opt/bitnami/apps/wordpress/htdocs# ls wp-content/
cache      languages  themes   upgrade-temp-backup  w3tc-config
index.php  plugins    upgrade  uploads

さらに、データベースのダンプデータ（バックアップデータ）も取得しておきます。

#mysqldump -u bn_wordpress -p bitnami_wordpress > bitnami_wordpress.sql

この後はバックアップデータを移行先の Lightsail インスタンスに格納する必要があります。SSHでCLIから接続しても良いのですが、今回Advanced File ManagerプラグインのFTP機能を使ってアップロードすることにします。

後は必要なファイルと、データベースの取り込みをすれば作業完了ですが「このサイトに重大なエラーがありました」が発生しました。

wp-config.php のデバッグ設定をONにしてデバッグします

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_DISPLAY', true);

define( 'WP_DEBUG_LOG', true );

結果、今回は下記のエラーが発生していました
Fatal error: Uncaught Error: Call to undefined function create_function()
Fatal error: Array and string offset access syntax with curly braces is no longer supported
これらは、PHPのバージョンが上がって廃止になったものなので、create_functionを無名関数に置き換え、配列への波括弧によるアクセスを、角括弧に置き換えれば問題なく動きます（今回はテーマのファイルで発生していたため、少し発見が遅れました）

後はLet ‘s Encrypt を使ってSSL対応を行います。今回はbitnamiのイメージを使っているので、certbotではなくてbncertを使うことで恒久的なSSL対応が可能となります。
参考：AWS公式ドキュメント「Lightsail WordPress のインスタンスで HTTPS を有効にする」
https://docs.aws.amazon.com/ja_jp/lightsail/latest/userguide/amazon-lightsail-enabling-https-on-wordpress.html

FITSではGoogle Workspaceを利用しています。
あるとき、Googleグループのすべてのメールが閲覧できるという報告を受けました。
幸い、情報漏洩などの事故は起きていませんでしたが、今後に備えて原因の解明と対策を行いました。

原因の特定

原因はGoogle Workspaceの管理者ロール設定にありました。

以下のロールが割り当てられたメンバーは、グループ側の設定で閲覧制限をかけていても適用されずに閲覧が可能です。
・特権管理者
・グループ管理者
閲覧できる旨の報告をしてくれた方は、グループ作成業務の際にグループ管理者ロールを割り当てられていたため、意図せず全てのメールが閲覧できる状態でした。

対策

グループの閲覧権限は必要のない権限であったため、ロール権限からグループの閲覧権限を外すことを試みましたが、特権管理者ロールやグループ管理者ロールはプリセットなロールであり、権限の変更はできませんでした。

そのため、グループの閲覧以外の権限を同等にした管理者ロールを手動で作成し、そちらに現在のメンバーを移行することで対応しました。

注意点

この対応を行う際には以下の点に注意が必要です。

特権管理者ロールは特殊なロール（スーパーアドミン）であり、権限設定画面に明記されていない権限と紐づいています。
つまり、権限を手動で同等に作成したつもりでも、今まで出来ていた操作ができなくなることがあります。
例えば、Google WorkspaceとAWSのIAMを統合してSSOを利用する場合、特権管理者ロールを持っていないとそれらの設定や操作ができません。

– 参考リンク: Configure SAML and SCIM with Google Workspace and IAM Identity Center –

その他の対応方法

私が行った方法以外にも、以下のような対応方法が考えられます。

・管理者の権限の見直し
不必要に管理者権限を持っているメンバーがいないか確認し、権限を持つ人数を最小限に抑えること。管理者権限を持つ必要があるか確認を行い、必要のないメンバーからはその権限を削除する。

・情報の機密性の評価
共有される情報の機密性を評価し、Googleグループ内で共有すべきでない機密性の高い情報は、もっとセキュアな方法（例えば、エンドツーエンド暗号化を提供するプラットフォーム）で共有することを検討する。

まとめ

組織でGoogle Workspaceを運用する場合、管理者権限は情シスなど一部のメンバーに限定しプロジェクトメンバーには権限のサブセットをロール化するのが基本となります。
もし管理者権限を運用されているのであれば、不要な権限を与えてしまっていないかと、
別途ロールを発行することが可能か検討するのが良いかもしれません。

結論から言うと「laravel-admin自体は動くけどartisan adminの一部のコマンドが動かない」という状況になります。laravel11ではこちらのリンクにあるようにDoctrine DBALの依存関係がなくなっています。

https://laravel.com/docs/11.x/upgrade#doctrine-dbal-removal

なのでlaravel-adminを使いたい場合は、laravel10の導入が選択肢となりそうです。

laravel11とlaravel-adminの導入

laravel11導入とlaravel-adminのインストールを順を追って説明すると、まずは公式の

https://readouble.com/laravel/11.x/ja/installation.html

にあるインストールコマンド（下記はMacOSの場合）

curl -s "https://laravel.build/laravel11" | bash

でlaravel11をインストールします（URLの末尾はアプリのディレクトリとなる）。インストールが終わったらコンテナを起動しましょう

cd laravel11
./vendor/bin/sail up

コンテナが起動したら

./vendor/bin/sail artisan migrate

これだけでlaravel11はインストール完了です。とっても簡単ですね。

次に、laravel-adminを導入していきます。

./vendor/bin/sail composer require encore/laravel-admin
./vendor/bin/sail artisan vendor:publish --provider="Encore\Admin\AdminServiceProvider"
./vendor/bin/sail artisan admin:install

こちらもとっても簡単ですね。

次に、モデル用のコントローラーを生成するためにいつものコマンドを叩いたところエラーが発生。

./vendor/bin/sail artisan admin:make UserController --model=App\\Models\\User

   BadMethodCallException 

  Method Illuminate\Database\MySqlConnection::isDoctrineAvailable does not exist.

  at vendor/laravel/framework/src/Illuminate/Macroable/Traits/Macroable.php:112
      108▕      */
      109▕     public function __call($method, $parameters)
      110▕     {
      111▕         if (! static::hasMacro($method)) {
  ➜ 112▕             throw new BadMethodCallException(sprintf(
      113▕                 'Method %s::%s does not exist.', static::class, $method
      114▕             ));
      115▕         }
      116▕ 

  i   Bad Method Call: Did you mean Illuminate\Database\MySqlConnection::availableAt() ? 

んん？なんでしょうこれは。と思って調べるとバッチリ「Laravel11ではDoctrine DBAL関連のメソッドが削除された」と出てきますね。

代替としてSchema::xxxを使えとあるのですが、現時点ではlaravel-adminがこれに対応するかどうか不明ですので、一旦laravel11とlaravel-adminの組み合わせは選択肢から外すのが良さそうです。