こんにちは。ソリューションアーキテクトの原田、鈴木、西亀です。 2026 年 6 月 25 日（水）〜 26 日（木）に幕張メッセで開催される AWS Summit Japan 2026 の AWS Builders’ Fair にて、私たちが制作したデモ「 Living Mart — AI エージェントが経営するお店 」を展示します。 本記事では、このデモを作った背景と、会場でどんな体験ができるのかをご紹介します。 技術的な詳しい解説は Summit 後の別記事で予定 していますが、まずは「面白そう！行

トリビューでCTOをしている小尾（@obiyuta）です。 弊社ではAIを前提とした全社業務の再構築に取り組んでおり、前回はその中で取り組んでいる社内MCPを載せる共通基盤（認証・認可・ログ）をご紹介しました。 今回は具体的な活用事例として、非エンジニアが自分で本番データを分析できるような分析基盤と、作って終わらない改善ループをどう”小さく”構築、運用しているかご紹介します。 「SQLが書ける」と「正しく答えられる」は違う 分析基盤そのものは特殊なものではなく、ClaudeやNotion AIなどから自然

はじめに 株式会社 MIXI は、コミュニケーションを軸に、ソーシャルネットワーキングサービスからゲーム、スポーツ、ライフスタイルサービスへと事業を多角化してきた日本の企業です。「モンスターストライク」や「家族アルバム みてね」といったサービスに加え、FC東京をはじめとするプロスポーツチームの運営を通じて、人と人との豊かなコミュニケーションの場を提供しています。 本記事では、MIXI が FC東京向けに開発した「写真選定業務効率化システム」のバックエンドデータベースとして、Amazon Aurora DS

こんにちは、ソリューションアーキテクトのシャルノ ミカエルです。 本記事では、2026 年 6 月 25 日（木）と 26 日（金）の 2 日間、幕張メッセで開催される AWS Summit Japan 2026 のブース予告をお届けします。製造業に関する展示は AWS Expo 内の AWS for Industries です。このブログでは、その中から「 ソフトウェア定義型ファクトリー 」と題して、ソフトウェア PLC とコーディングエージェントで工場制御の開発を変革するテーマについてご紹介します。

1. はじめに この記事で書くこと この記事で書かないこと 前提 2. バージョンアップ作業フロー Step 1：メジャーバージョンアップによる影響調査 Devin の Playbook を作成する Devin の Playbook を実行して一覧化する Step 2：対応が必要かどうかの判断と方針検討 Step 3：更新作業 3. AI 活用の所感 影響度判定の精度評価 良かった点 微妙だった点・反省 4. まとめ 5. 今後の展望 参考文献 1. はじめに ラクスが開発する請求書受領システム「楽楽請求

報告者：柾本 彬（技師 / 技術推進グループ・softcreate）　 会期：2026年6月2日(火)〜3日(水) 会場：Fort Mason Center マイクロソフトが毎年開催している開発者向けイベント「Microsoft Build 2026」に参加してきました。ガチガチの技術レポートは参加した各社の優秀なエンジニアの方々が書いてくれていますし、同行した若き？エンジニア達も書いてくれそうなので一旦置いておいて、「現地に行って参加するってこんな感じなんだなぁ」というレポートをさせていただきます！ 個

こんにちは、クラウドエース株式会社第三開発部の小勝です。 現在（執筆時点では2026年6月16日）は新卒2年目です。昨年新卒1年目から約半年で Google Cloud Partner All Certification Holders を達成しました。25年度の All Certification Holders では Professional Security Operations Engineer（PSOE）が対象外でしたが、その後 PSOE も取得し、 Google Cloud 認定資格をすべて取

第1回 では、AI時代に求められる思考力とは何かを問い直しながら、「抽象化」と「アナロジー」という武器の正体を解き明かしました。 分類学をアナロジーに、クジラとカバが実は親戚であるという驚きとともに、具体から本質を抜き出す面白さを感じてもらえたでしょうか。 今回はいよいよ実践編。抽象化とアナロジーを、テスト・QAの現場でどう使うか。テスト観点の洗い出し、同値分割法、状態遷移モデル、そして過去の不具合や競合製品からの類推まで、具体的な手法を通じて「考える力」を使いこなすヒントをお届けします。 抽象化をテスト

ども！最近、スライドをAIと一緒にレビューし続けている龍ちゃんです。 正直に言うと、セミナー資料づくりは全然得意じゃないです。話の組み立ても見せ方も、上手い人にはぜんぜんかなわない。だからこそ、自分が作ったスライドはAIにレビューさせて、自分では気づけない穴を埋めるようにしてます。専門外のことほど、AIのチェックを最初から仕組みとして組み込んでおきたいんですよね。 で、最初にやったのが「1体のAIに全部やらせる」でした。結果、時間だけがかかって前に進みませんでした。 AIに「レビューして」と丸投げすると、

ども！最近、社内セミナーのスライドをAIと一緒に作り続けている龍ちゃんです。 「AIにスライド作ってもらえば楽じゃん」と思って、一発で頼んだことありますよね。わかります。僕も最初はそうやってました。返ってきたのは、きれいで整ったスライドでした。でも見た瞬間、「あ、なんか違う」ってなるやつです。 直そうとすると、直すたびに別の何かがズレる。修正ループが延々続いて、最終的に自分でほぼ作り直す羽目になる。何度か繰り返してようやく「これ、頼み方の問題だ」と気づいたんですよね。 今回の話は、「速くする魔法」でも「修

手作業じゃ間に合わない、だからAIで作れる環境を整えた ども！Slidev と Claude Code でスライドを量産してる龍ちゃんです。 ここ最近、ほんとにスライドばっかり作ってるんですよ。セミナー、勉強会、社内共有……気づけば毎週どこかで1本。正直、これを1枚1枚手作業でデザインしてたら、どう考えても間に合わない。 なので、AIに作らせることにしました。ただ、AIに丸投げすると、トーンがバラバラになります。色は勝手に増えるし、変なグラデは湧くし、フォントも気分で変わる。それっぽく見えるんですが、その

AIにスライド、全部任せちゃダメなの？ ども！Slidev と Claude Code でスライドを量産してる龍ちゃんです。 前回（第3部） で、色やサイズを CSS変数で縛る話をしました。今回はその続きで、もう一段上の「育てる」話なんですけど、その前にひとつ、最近ふと思うことがあって。 AIにスライド、もう全部任せちゃえばよくないですか？って。 実際、ソースをポンと放り込んだら構成も中身も全部AIがまとめてくれるツール、増えましたよね。資料を要約する・理解するみたいな用途なら、全任せで十分だと思います。

AIは結構ちゃんと作る。でも“揃わない”し、たまに事故る ども！Slidev と Claude Code でスライドを量産してる龍ちゃんです。 念のため前提だけ。Slidev は Markdown でスライドを書けるツール で、この連載の話は全部その上に乗ってます。今回のトークンも、Slidev プロジェクトの style.css に置く前提です。Slidev 自体のセットアップは 第1部 に。 前回（第2部） で「部品化して育てるなら Slidev」って話をして、最後に予告したやつですね。今回はその一番

Marp と Slidev、どう使い分ける？ ども！ もともとスライドは全部 Marp で作ってて、そこそこ使い倒した末に Slidev へ移った 龍ちゃんです。 Marp と Slidev は、どっちも Markdown でスライドを書ける 開発者向けのツールです。で、両方を触ったことがある人なら、一度はこう思いますよね。 龍 「結局、 どっち使えばいいの？ 」 僕は両方を Claude Code で使い倒してきました。Marp は 80時間→11時間に短縮した話 を書いたくらい使い込んだし、その上で今

AIで爆速、しかも Git 管理。スライド作りがコードになった ども！ Slidev と Claude Code を組み合わせてスライド作りにハマってる龍ちゃんです。 Slidev は Markdown でスライドを書ける、開発者向けのプレゼンツール です。テキストボックスをマウスで並べる代わりに、見出しや箇条書きを Markdown で書くと、それがそのままスライドになる。コードブロックもそのまま貼れてシンタックスハイライトも効くので、LT や登壇資料を作るエンジニアに人気のやつですね。 で、これを C