みなさん、こんにちは。AWS ソリューションアーキテクトの古屋です。 日々のお客様との会話の中で、「業務課題を解決するために新たな機能やシステムの開発が必要ではあるが、外部リソースを確保する余力もなく、自社に十分なエンジニアもいないため実現が難しい」というお声をいただきます。同様のお悩みをお持ちの方も少なくないのではないでしょうか。 近年、そういった状況に対して、 Amazon Bedrock や Amazon Q Developer をはじめとする AWS の生成 AI サービスの登場により、限られた開発リソースの中でも、業務を最もよく知る現場の担当者自身が課題解決の仕組みを構築できる環境が整いつつあります。 今回は、まさに生成 AI を活かし、非エンジニアのメンバーが中心となって契約書管理 AI エージェントを構築された大成株式会社様の事例をご紹介します。本事例では、Amazon Q Developer によりプログラミング経験が限られたメンバーでも AWS 上でのシステム構築が可能となり、さらに Amazon Bedrock を利用することでインフラ構築や運用管理なしに Claude のような高性能な基盤モデルを API 一つで呼び出せるため、従来手作業で数十分かかっていた情報抽出を数分に短縮する仕組みを短期間で実現いただきました。 お客様の状況と経緯 大成株式会社様（以下、大成様）は、「ビルトータルソリューション」を掲げ、ファシリティマネジメント、プロパティマネジメント、不動産投資事業、修繕工事や改修工事などの建築事業を展開する総合サービス企業です。 大成様のプロパティマネジメント業務では、ビルオーナー様やテナント様との間で締結される多数の契約書が業務の根幹をなしています。しかしながら、従来の契約書管理では、以下の課題が存在していました。 契約書の検索が手作業に依存しており、必要な情報を見つけるために複数の PDF を開いて目視で確認する必要がある テナント様ごとに契約内容の仕様が異なるため、ビル名やテナント名だけでは目的の契約書にたどり着けない場合がある ビルオーナー様からの問い合わせに対し、契約書の特定から情報確認、回答までに多くの時間を要し、迅速な顧客対応の妨げとなっている これらの課題を解決するため、業務改善やシステム利活用を担当している IT 戦略推進室が本取り組みに参加しました。大成様では社内 SE、内製開発を行うエンジニアを擁していないため、同部にて生成 AI を活用した契約書管理システムの構築を検討されることになりました。 ソリューション／構成内容 本プロジェクトでは、非エンジニアのプロジェクトマネージャーが中心となり、Amazon Q Developer の支援を受けながらシステムを構築しました。Amazon Q Developer は自然言語での指示に基づいてコードを生成する AI アシスタントであり、プログラミング経験が限られた担当者でも実用的なシステムを構築できます。 本システムでは、Amazon Bedrock、 AWS Lambda 、 Amazon S3 、 Amazon DynamoDB を組み合わせて活用しています。Amazon Bedrock は生成 AI の中核を担い、Anthropic 社の Claude AI モデルを通じて契約書 PDF の解析と重要情報の抽出を実行します。 Amazon Bedrock + Claude を採用したポイントとして、Claude の高度な文書理解能力が挙げられます。契約書は法的な専門用語を含む複雑な文書であり、テナント様ごとにフォーマットが異なりますが、Claude は PDF などの非構造化データから文脈を理解した上で必要な情報を正確に抽出できます。また、AWS Lambda を中心としたサーバーレスアーキテクチャにより、非エンジニアが中心のチームでもインフラ管理に煩わされることなくシステムを運用できる点、そして日常的に使用している Slack との統合が容易で導入時の移行障壁を低く抑えられる点も、AWS を選択された理由です。 導入効果 実際にご利用いただいた結果、以下のような効果が得られています。 契約書からの情報抽出にかかる作業時間を 約 70〜80% 削減 。従来 1 件あたり数十分を要していた作業が数分で完了 将来的には、CSV 形式でのデータ出力機能を実装し、契約書情報の一括管理および分析を可能とする仕組みの構築を検討 AI による解析で情報抽出の精度と一貫性が向上し、人手による見落としや誤読のリスクを低減 Slack 上のシンプルなワークフローにより、従業員の受け入れがスムーズに また、非エンジニアでも Amazon Q Developer の支援により AWS の各種サービスを組み合わせた実用的なシステムを構築できることが実証されたことにより、他の業務領域でも生成 AI を活用した業務改善の取り組みが始まるきっかけとなっています。 大成様では今回の成功を踏まえ、契約書の自動要約機能や自然言語での高速検索機能の追加を検討されています。さらに、施設管理報告書の自動生成やメンテナンス記録の分析など、プロパティマネジメント業務全般での AI 活用拡大も計画されています。 お客様の声 大成株式会社 IT 戦略推進室 石川 静華様からは、「AWS のサービスを使うことで非エンジニアでも実業務の課題を自らの手で解決できる喜びを実感しました。」とのコメントをいただいています。 まとめ 今回は大成様が Amazon Bedrock と Amazon Q Developer を活用し、非エンジニアの手で契約書管理 AI エージェントを構築された事例をご紹介しました。Claude の高度な文書理解能力とサーバーレスアーキテクチャの組み合わせにより、専門的な開発リソースがなくても実用的な業務改善システムを実現されています。スモールスタートで確実に成果を出すアプローチは、これから生成 AI 活用を検討される企業にとっても参考になる取り組みです。 生成 AI を活用した業務改善にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください。 大成様 IT 戦略推進室 推進課 課長　田島 宏美 IT 戦略推進室 戦略課 主任　石川 静華 IT 戦略推進室 推進課 主任　鎌倉 由佳 Account Team： ソリューションアーキテクト　森   瞭輔 アカウントマネージャー　植木　輝 記事執筆： ソリューションアーキテクト　古屋　楓

はじめに BASE Order Section でWebアプリケーションエンジニア をしている Capi(かぴ) です。 2026/3/20（金）- 3/22（日）の3日間、BASE株式会社もゴールドスポンサーとして協賛した PHPerKaigi 2026 が開催されました。今回はPHPerKaigi 2026に参加したメンバーのコメントや感想をお届けします！ PHPerKaigiとは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。コミュニティ貢献活動の一環として、今年もゴールドスポンサーとして協賛しました。 登壇者コメント 川島慧 モジュラモノリスを導入してから4年が経ち、「そろそろ答え合わせができるのでは」という気持ちで今回の発表に臨みました。 「何を解決しようとしているのか分からないままマイクロサービス（orモジュラモノリス）を開始しようとするのはほとんど悪いアイディアだ」という、技術主導は大抵誤りであるという意識を４年前からずっと持って挑んできました。結果的に思いがけないつまづきもありましたが、無事に解決するべきIssueの解像度が上がった４年間でした。 スライド中では「AIに要約させながら読むことを推奨」と書いたのですが、アップロード後に試してみると、意外なことにChatGPTやGeminiでは何度訂正させても全く違う内容が返ってきました。どうやら100枚超のスライドをAIに要約させるのはまだ難しいようです。ClaudeとNotebookLMだとある程度うまくやってくれます。 個人的にはかなり痛手です。これほどの文量を読むエンジニアは今の時代にまずいないので、ほとんどの人に届かない内容になってしまったと思います。スライドを読む際はご自身の目でしっかり読んでいただくか、動画を見るか、ClaudeまたはNotebookLMあたりににお願いするのがおすすめです（個人の感想です）。 speakerdeck.com プログラミングをするパンダ セール開始のバッチのパフォーマンスをチームで改善したという話を共有しました。発表後に「うちでも遅いバッチがある」という話を聞いたり、「しっかり遅いことに気づいて改善に持っていける体制が作られているのが素晴らしい」とお褒めの言葉をいただいたりしました。 特にポストモーテム共有会をやっているということが今回のバッチの改善の起点になったのですが、その取り組みがとても良いと言ってもらうことが多く、ポストモーテム共有会も別のメンバーが始めていたので大変ありがたいなと思っています。 スライドの最後の方でも触れましたが、今回の発表を機にもう一段改善できるところを見直そうと思うので、さらに早くできるのではないかなと思っています。当日発表を聞きに来てくださった方、ありがとうございました。そうでない方もぜひスライドを一度ご覧ください。皆様のお役に立てれば幸いです。 speakerdeck.com 02 PHP8.5に追加されたarray_first / array_lastの歴史的背景について話しました。5分という短い時間で7年分の議論の流れを追いましたが、重要な話はできるだけ削らずに伝えられたと思います。 さまざまな観点から議論を重ねて未解決の疑問をなくす必要がある一方で、発散した議論はスコープを絞ったり、特定の観点を重視して仕様を決めたり・・・仕事の進め方やファシリテーション、マネジメントなど、普段のプロダクト開発で重要な力が、RFCの採択においても重要だという所感を感じました。 PHP Internalsの議論の流れを追う中で学びが多く、今回のarray_first / array_last以外の議論も追ってみたいと思いました。興味を持った皆さんも、まずは参考文献のURLからarray_first / array_lastの議論を追ってみてください！ speakerdeck.com パンフレット記事執筆者コメント meihei 「カンファレンスが終わったあとに」というパンフレットを寄稿しました。先日のPHPerKaigiでは多くの学びがあったかと思います。それらを自分の中で、またチームメンバーとともに知識として再構築し、今後さまざまな機会で活かせる武器にしてもらえたら嬉しいです。 パンフレットはマンガで解説していますので、お気軽にお読みください！ 現地で見たセッションを一部紹介 当日イベントに参加した自分含む弊社メンバーが現地で見たセッションのうち特に気になったセッションのレポートです！ 1. 「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜 by 武田 憲太郎さん 高トラフィックを捌く技術的な解決を自信持って行うためにできることを紹介していただきました。アプリケーションコードよりもミドルウェアの話が中心でした。 Keep Alive、Persistent Connection、コネクションプール… 単語は知っているけれど自分が使いこなせていないものがたくさん出てきて非常に勉強になりました。スライドには図やグラフ、コードが添付されていたので難しい内容でも理解しやすかったです。興味のある方はぜひスライドだけでもみていただきたいです。オススメです。 自分は登壇の中で武田さんがおっしゃっていた「計測は仮説を持って行う」という言葉が印象に残っています。また、登壇を聞きながらシステムの接続はとても奥が深く技術者の腕の見せ所なのではないかと考えました。 (BASE Order Section @Capi) 2. プログラミング言語論から覗くPHPの正体 by うさみけんたさん 「PHPがどんな歴史を積み重ね、今の書き方になったのか」を紐解いていきました。PHPがゆるふわ言語というのは自分もなんとなく理解していますが、想像以上にゆるふわ言語であることを知り、PHPらしさを再度認識する良い機会になりました。 また、登壇の中ではPHP作者Rasmus Lerdorf(ラスマス・ラードフ)氏の発言を取り上げていました。言語作者の人となりを知るのも面白いなと登壇を聞きながら考えました。なぜ言語が作られたのか、どんな思想で言語が成長してきたのかを知ることでその言語への愛着が強まります。 登壇で出てきたこのスライドが自分は好きです笑 (BASE Order Section @Capi) 3. 俺の/私の最強アーキテクチャ決定戦開催 ― チームで新しいアーキテクチャに適合していくために by 髙橋直規さん 持続可能なチーム開発を目指す中で、「アーキテクチャを刷新する必要があるが、トップダウンで決めるのは避けたい」という背景から、「最強アーキテクチャ決定戦」を開催したという内容のライトニングトークでした。 2人程度で似たようなイベントを開催したことはありましたが、経験値に差があるチームで実施したことはなかったため「すべての処理を神メソッドで実現する」という提案のハードルを下げるための工夫や、イベントの流れなど開発チームの運営において大変参考になる内容が多かったです。（Pay ID Engineering Section 岡部 @rerenote） 4.AI時代の脳疲弊と向き合う ~言語学としてのPHP~ by さくらいさん 日々の業務の中で、何かしらAIとやりとりする機会が増えています。その中で、抽象的な内容を具体的な表現に落とし込む場面が以前より多くなっていると感じていました。また、AIと長時間やりとりした後に強い疲労感を覚えることも増えてきています。 このライトニングトークでは、こうした疲れがどこから生じるのか、そしてその対策について解説されていました。対策の中でも「意識して時間を使い分ける」はすぐに実践できそうだと感じ、早速取り入れています。以前と比べて、疲労感を覚える場面が少なくなってきたように感じています。（Pay ID Engineering Section 岡部 @rerenote） おわりに 去年に引き続きレポーターとしてPHPerKaigiに参加させていただきました。 今年も協賛活動、社員のスピーカー参加を通して PHPコミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました。 スタッフの方々には業務でお忙しいにも関わらず、多くの時間をイベント準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。

こんにちは。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 .