セキュリティサービス部 佐竹です。 本ブログでは、AWS Direct Connect に関する2つの新しいアップデートについて、その有効性をまとめました。1つ目が DX が BGPモニタリング用の CloudWatch メトリクスを追加したこと。2つ目が CloudFormation サポートが発表されたことです。

こんにちは。Sqripts編集部のハチワレです。 最近は生成AIに携わることが多く、日々の進化を驚きと喜びを感じながら眺めています。そして、「コードを書く」ことの垣根がどんどん低くなっていることも、「AIってすごいな～」ぐらいの気持ちでただただ感心して眺めておりました。 今回は、そんな私が実際に遭遇した「ちょっとヒヤッとした話」をもとに、生成AI時代の実装リスクについて書いてみたいと思います。 あくまで「とあるDX現場の物語」として読んでいただければ幸いです。 ※本記事は、実際に現場で起きた出来事をもとに構成しています。登場人物・インシデントの内容は一部変更しています。 ある日、フォームが動かなくなった 「フォームが表示されません」 こんな連絡が届いたのは、ごく普通の業務日のことでした。 確認してみると、たしかに挙動がおかしい。コードに少し修正を加えるように伝えると、今度はこう返ってきました。 「フォームは動きましたが、フォーム送信完了ページ（サンクスページ）が404です！」 ……サンクスページが、ない！？（404は「ページが見つかりません」のエラーコードです） 調査を進めてみると、MA（マーケティング・オートメーション ※ ）側の設定を、あるマーケティング担当者が生成AIと対話しながら変更していたことがわかりました。 ※マーケティング・オートメーション（MA）とは、フォームの発行、ユーザー管理、メール配信など、マーケティング活動に関わる様々な機能を持つツールのことです。 「動いた」と「大丈夫」は、まったく別の話 その担当者に、開発の経験はありません。 それでも、生成AIに「やりたいこと」を自然言語で説明してJavaScriptのコードを生成してもらい、MAに実装することができました。 コードは動き、担当者は大きな成功体験を得ました。 問題は、誰もその「先」を確認していなかったことです。 — ここで少し、「影響範囲」という概念についてお話しさせてください。 システムやWebサイトを構成するコードは、それぞれが独立しているようで、実はさまざまな形でつながっています。あるページの挙動を変えるコードが、別の処理の前提条件になっていることも珍しくありません。 今回のフォームと送信完了ページがまさにそれでした。 表から見ると、「フォームを送信する。送信後に『ありがとうございました』のようなページが表示される」というシンプルな存在です。しかし裏側では、いくつかの処理が連鎖していました。 フォーム送信の完了を検知して計測する処理 送信者の情報をほかのツールに連携する処理 担当者への通知やスコアリングに関わる処理 など、このフォームから送信完了ページへの遷移は、「ユーザーが正常にフォームを送信した」というシグナルでもあったわけです。そのシグナルを受けて、複数のシステムが動いていました。 変更されたコードは、この一連の流れに割り込みました。結果、送信完了ページは404エラーを返し、連携データは正常に記録されなくなっていました。フォームそのものは見た目上は「動いて」いましたが、その裏側で起きるべきことが、静かに止まっていたのです。 影響範囲スコープの例 フォームが「動いた」のは確かです。でもそれは、「大丈夫」ではありませんでした。 影響範囲とは、「自分が触れたコードが、どこまでの処理に関係しているか」という見取り図のようなものです。この見取り図を持っているかどうかが、「動かせる」と「安全に実装できる」の分かれ目になります。 悪意があった人は、誰もいない 誤解のないようにお伝えしておくと、今回の件で悪意があった人は一人もいません。 担当者は業務を効率化しようとしていましたし、生成AIを活用しようとしていました。その姿勢は、むしろ前向きです。 Webサイト側の担当者も、相談は受けていました。ただ、コードの中身をレビューできる知識はなく、「何かを変えるらしい」とは知っていても、何がどう変わってどんな影響が出るかまでは判断できませんでした。 そして、もうひとつ大事なことがあります。 実装した担当者は、そもそも「フォームや送信完了ページに『他の働きをする何か』が仕込まれている」という知識を持っていませんでした。表から見ればただの入力フォームと送信完了ページ。まさか、その裏側でツール連携や計測が動いているとは、思いもよらなかったのです。 「確認しなかった」のではなく、「確認すべきものがあると知らなかった」。これは責める話ではありませんが、だからこそ厄介です。本人の注意や意識だけでは、防ぎようがない。 誰も手を抜いていないのに、システムは壊れた。 これが今回、私が一番伝えたいことです。 「コードが書けない」という壁が、なくなった 少し前まで、「コードが書けない人」はコードを書きませんでした。当たり前のことですが。 やりたいことがあっても、実装する手段がない。だから、担当範囲を超えた変更は物理的に起きにくかったのです。 「この機能を変えたい」と思っても、コードが書けなければエンジニアに依頼するしかない。依頼するということは、必然的に「何をどう変えたいのか」を説明し、確認してもらうプロセスが発生する。面倒に感じることもあったでしょうが、このプロセスが「影響範囲の確認」を担っていたと言えます。 生成AIは、その壁を取り払いました。 プログラミングの知識がなくても、やりたいことを言葉で説明すれば、動くコードが出てきます。エンジニアへの依頼も、確認のプロセスも、必要なくなりました。 これ自体は、すごいことです。間違いなく。 ただ、壁が取り払われたとき、同時に「ゲート」も消えてしまいました。 エンジニアが影響範囲を判断するタイミング、このプロセスが、いわば「実装前のゲート」として機能していたのです。生成AIによって誰もが一人で完結できるようになったことで、そのゲートもなくなってしまいました。 「書けるようになった」と「わかるようになった」は、まったく別の話です。 生成AIはコードを書いてくれます。でも「このコードが既存のシステムと干渉しないか」「影響を受けるのはどの処理か」「変更前に誰に相談すべきか」という問いを立てられるのは、影響範囲の見取り図を持っている人、つまりシステム全体を俯瞰して把握している人だけです。 もちろん、生成AIにその見取り図を渡すことができれば影響範囲の判定もしてくれます。 ですが、見取り図を持たない人に、その「問いを立てる力」は、生成AIは与えてくれません。（今のところ） だからこそ、「人間が介在する」設計が必要になる ここで、AIの世界でよく使われる概念をひとつご紹介したいと思います。 HITL（Human-in-the-Loop） という考え方です。 AIによる自動化されたプロセスに、意図的に人間が介在する仕組みのことを指します。AIが得意な「大量処理・高速生成」と、人間が得意な「判断・文脈の理解・倫理的な配慮」を組み合わせることで、より質の高い結果を目指す、という発想です。 私はこの概念がとても好きで、AIの活用を考えるときの基本的な視点として大切にしています。 今回の件は、まさにHITLが機能していなかったケースです。 生成AIがコードを生成する→人間がそのまま実装する、という流れに、「影響範囲を判断できる人間」が介在していなかった。AIの出力を人間がレビューし、「これは既存のシステムに影響しないか」「担当者に確認が必要ではないか」と判断するステップが、すっぽり抜けていました。 AIを使うこと自体が問題なのではありません。AIの出力をそのまま「正解」として扱い、人間の判断を挟まなかったことが、問題だったのです。 「これ、大丈夫なやつ？」という感覚 私はこれを、「大丈夫チェック」と呼んでいます。 コードを実装する前に一瞬立ち止まって、「これ、大丈夫なやつ？」と自問する。シンプルな問いですが、これができるかどうかが、今の時代に大きな差を生むのではないかと思っています。 具体的には、こんな確認です。 全体のシステムのどの部分に触れる変更か 既存のコードや設定と干渉する可能性はないか 担当者への事前確認は完了しているか こうした確認を、属人的な「声かけ」に頼るだけではなく、チームの手順として持っておくこと。それが「動いた」と「大丈夫」のギャップを埋める方法だと、今回の経験から強く感じました。 そして、この「大丈夫かどうか」を 仕組みとして担保する のが、「テスト」という考え方です。 変更後に期待通りに動くかを確認するだけでなく、「既存の動作が壊れていないか」を検証するテスト（リグレッションテストと呼ばれます）は、まさに今回のようなケースの再発を防ぐための安全網になります。 生成AIが実装の入口を広げたことで、テストの重要性もまた、以前より増していると感じています。 関連記事 リグレッションテストとは？目的、実施タイミング、実施方法、自動化について解説 リグレッションテストとは「リグレッションテスト」（Regreesion Test／レグレッションテスト）は、ソフトウェア開発におけるテスト手法のひとつで、「回帰テスト」「退行テスト」とも呼ばれます。リグレッションテストは、プログラムの修正や変更を行った際に、変更... 　続きを読む　 Sqripts まとめ 今回お伝えしたかったことを整理すると、こうなります。 「動いた」≠「大丈夫」 ：生成AIが生成したコードが動作することと、既存システムに悪影響を与えないことは別の話 壁がなくなった時代のリスク ：誰でも実装できるようになったからこそ、「影響範囲を測る」プロセスの重要性が増している 悪意より怖い「善意のインシデント」 ：誰も悪くないのに壊れる、というケースへの備えが必要 「問いを立てる力」は人間が持つ ：生成AIはコードを書いてくれるが、「これ大丈夫？」と問えるのは、構造を知っている人間だけ HITLの視点を持つ ：AI任せにするのではなく、判断できる人間がプロセスに介在する設計を意識する 「テスト」は「大丈夫」を仕組みにする手段 ：変更が既存の動作を壊していないかを確認するテストが、善意のインシデントを防ぐ安全網になる 生成AIの登場で、ソフトウェアに関わる実装のハードルは確実に下がっています。だからこそ、「実装してよいかを判断する人・仕組み」の価値は、むしろ上がっているのではないでしょうか。 この記事が、どなたかの現場での一助になれば幸いです。 最後までお読みいただき、ありがとうございました。 本記事は、実際にとあるDX現場で起きた出来事をもとに構成しています。登場人物・インシデントの内容は一部変更しています。 ▼非エンジニアにもおすすめの関連記事 関連記事 Generative AI Leader（生成AIリーダー）認定資格試験を受けてみた｜知識ゼロから始めた学習方法と試験対策 こんにちは。Sqripts編集部のハチワレと申します。かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。「非エンジニア」を称しています。今回は、非エンジニアの私がGoogle Cloudの認定資格、Generati... 　続きを読む　 Sqripts 関連記事 生成AIの基礎リテラシーと明日から業務で使える活用術 こんにちは。Sqripts編集部のハチワレです。かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。技術と非技術の狭間に佇み、両方の世界を行き来する日々を過ごしております。前回は「Generative AI Le... 　続きを読む　 Sqripts The post AIがコードを書いた。動いた。でも、システムは壊れていた話。 first appeared on Sqripts .

こんにちは。Insight Edge（以下、IE）でデザイナーをしている水上です。 この記事では、IEのブランドロゴとコーポレートサイトを全面的につくり直したプロジェクトについて、制作プロセスとその裏側をお伝えします。 設立6年目、なぜ今リニューアルが必要だったのか 最初に決めたルール：「好き嫌い」でデザインを判断しない まずは「IEらしさ」を3つの言葉にした 不可能図形「ペンローズの三角形」をロゴにした理由 サイトは「IEを言葉で伝える場所」にした リリースはゴールではなくスタート 設立6年目、なぜ今リニューアルが必要だったのか IEは住友商事グループのデジタル・AI専門組織として、2019年に設立されました。グループ各社の事業課題に入り込み、構想から実装まで一貫して伴走するのが私たちの仕事です。 私はIEで約2年、プロジェクトやマーケティング、イベントのデザインを担当してきました。その中で、IEがグループ内でどんな立ち位置にあり、何を期待されているのかが少しずつ見えてきました。 一方で、設立から6年が経ち、私たちを取り巻く環境は大きく変わっていました。生成AIの急速な進化、グループ外への展開、グローバル案件の増加。従来のロゴは線が細くフラットな印象で、競合と並んだときに埋もれてしまう。サイトもIEの独自性を十分に伝えきれていない。事業の発信を強化し、一緒に働く仲間を惹きつけていくために、ブランドの土台から見直す必要がありました。 最初に決めたルール：「好き嫌い」でデザインを判断しない プロジェクトの最初に、私はひとつのルールを決めました。「かっこいい・かっこよくない」でデザインを選ばない、ということです。 ロゴやサイトは個人の作品ではありません。IEという組織のための、戦略的なデザインです。「どの選択がIEにとって最適か」を常に判断基準にする。この前提をプロジェクトの軸に据えました。 具体的には、IEのMission / Vision / Valueを土台にして、まず「IEはどんな性格の組織か」を定義する。その上で、競合との違いや顧客に届けたい印象を明確にしてからデザインに落とし込む。いわば、土台から順番に積み上げていくアプローチです。 まずは「IEらしさ」を3つの言葉にした デザインをつくる前に、私はまず「IEらしさとは何か」を言葉にする作業から始めました。 DX・AI領域には似たポジションの企業がたくさんあります。その多くが「実行力」「安定感」「知性」をブランドの軸にしています。IEも同じ方向に寄せるのではなく、自分たちならではの色を出す必要がありました。 競合分析と社内の議論を重ねて辿り着いたのが、IEのバリュー「やり抜く・やってみる・みんなでやる」と結びつく3つのコアパーソナリティです。 推進力（Drive） ：仮説を立てたらすぐ動く。プロトタイプから実装までやり切るスピードと覚悟。 共創力（Co-Creation） ：顧客と同じ目線で課題を掘り下げ、一緒にビジネスの価値をつくる力。 探索力（Exploration） ：AI・生成系技術・まだ見えていない課題領域に先回りして踏み込む姿勢。 不可能図形「ペンローズの三角形」をロゴにした理由 言葉が決まったら、次はそれをどう形にするか。ここからが実際のデザイン作業です。 大手総合商社内のグループ企業の中でどう見られるか、常に俯瞰の視点を意識すること。先端テクノロジーを標榜する企業としての新鮮さと保守的な判断の際（きわ）を丁寧に探ること。経営陣との対話の中で何度も意識したポイントです。 そのバランスを探り続ける中で辿り着いたのが、3つのパーソナリティを3本の矢印とペンローズの三角形で表現するアイデアでした。 矢印は前に進む推進力。3つの方向は探索力。3本が組み上がる構造は共創力。そしてペンローズの三角形は、三次元に見えるのに実際には存在しえない「不可能図形」です。まだ形のない課題に対しても、多角的に向き合い、解決の道筋を切り拓く。IEが顧客と向き合うときの姿勢を、この図形に重ねました。 ブランドカラーには、すこし紫がかったウルトラマリンブルーを「IE Blue」として定義しました。住友商事グループのデジタル系企業はブルー基調が多い中で、IEらしい先進性を感じさせる色として選んでいます。 サイトは「IEを言葉で伝える場所」にした 今までIEはMission / Vision / Valueという柱のみでブランドを語ってきました。しかし、DX・AI領域のプレイヤーが急増する中で、それだけでは足りないと感じていました。IEに何を期待できるのか、どんなキャラクターの組織なのか――その解像度を上げるための言葉を、もっと丁寧に紡いでいく必要がある。経営陣との対話の中で繰り返し出てきたこの想いが、コーポレートサイト刷新の出発点です。 今回のサイトリニューアルの目的は、見た目を整えることではありません。IEが自分たちの言葉で語れる場所をつくることです。 デザインのトーンで意識したのは、「先進的で知的なテクノロジスト」としての顔と、「顧客と一緒にビジネスの価値をつくる」親しみやすさの両立です。IEにはコンサルティングの機能もあり、市場や顧客に直接向き合う場面が多い。だからこそ、テクノロジー企業にありがちなクールさだけでは足りない。シンプルな表現の中にどうこだわりを込めるかが、デザイン上の大きなテーマでした。 サイトのキービジュアルには、ロゴの三本の矢がそれぞれの方向へ広がり、再び結束するアニメーションを採用しています。個々の推進力や探索力がバラバラに動くのではなく、その先で新たなつながりを生み出していく。IEの働き方そのものを表現したいと考えて、この動きに辿り着きました。 ビジュアル素材にもこだわりがあります。サイト内のイラストにはAI生成を活用していますが、抽象的なイメージビジュアルではなく、実際の案件事例を補足する具体的なイラストとして制作しました。ブランドトーンに沿った色味やタッチを統一することで、IEの世界観を視覚的に支える役割を持たせています。 メインメッセージは "Drive change with Insight. ― 技術と経験を磨き、共に未来の一歩をつくり出す。" です。変化の激しい領域で歩みを重ねてきたIEが、これから目指す姿勢を新しい言葉にしました。 リリースはゴールではなくスタート プロジェクトを通じて、経営・マネージャー陣には何度も率直な対話の時間をいただきました。忙しい中でブランドの言葉や方向性を一緒に考えてくださったこと、コーポレートサイトの仕上げに力を貸してくれた外部パートナー、そして個別事例や採用・翻訳に協力していただいた社内のメンバー。関わってくださったすべての方に、心から感謝しています。 DX・AI領域は変化のスピードが速く、今日の最適解が3ヶ月後には古くなっていることも珍しくありません。だからこそ、ブランドもデザインも、事業の成長に合わせてチューニングし続ける必要があります。 ここからまた一段と、IEの存在と価値を伝えるデザインをアップデートしていきます。 株式会社Insight Edge コーポレートサイト： https://insightedge.jp/