はじめに Vibe Coding、楽しいですよね。 Claude Codeに「こんな感じで作って」と伝えるだけで、AWSのリソースを使ったアプリがサクサク出来上がっていく。自分でコードを書く量は激減して、PoCなんてあっという間に完成する。 …と思っていた時期が、僕にもありました。 一人で作ったPoCを別の担当者に引き継ごうとしたら、 新環境でアプリが動かない 。原因を調べようにも、Vibe Codingで作ったから コードの中身を自分でも把握していない 。結局、原因解明に 約1週間 溶かしました。 この記事では、何が起きたのか、なぜ時間がかかったのか、そしてどうすれば防げたのかを共有します。 何を作っていたか Claude Codeを使って、一人でPoCを開発していました。 構成はこんな感じ： Amazon DynamoDB – データストア Amazon Bedrock Agent – LLMを使った処理 Amazon Cognito – 認証 典型的なサーバーレス構成です。Vibe Codingでガンガン作って、旧環境（開発用AWSアカウント）ではちゃんと動いていました。 事件：新環境で動かない 引き継ぎのタイミングで、新環境（別のAWSアカウント）にデプロイして動作確認をしました。 動かない。 エラーは出るけど、原因がよくわからない。Claude Codeにデバッグさせても、的を射た回答が返ってこない。 「コードを読めばわかるでしょ」と思うかもしれませんが、Vibe Codingで作ったので 自分でもコードの詳細を把握していない んですよね。どこを見ればいいかすらわからない。 原因：AIが勝手に書いたフォールバック値 結局、新環境と旧環境のデプロイ後の挙動の違いをClaude Codeに分析させて、やっと原因がわかりました。AWSのリソースやCloudWatchログを片っ端から参照させた結果です。 原因は 環境変数のフォールバック値 でした。 // ※ 以下はAIが生成した例示コードです。実際のコードとは異なります。 // config.ts export const config = { dynamoTableName: process.env.DYNAMO_TABLE_NAME || "dev-user-table", bedrockAgentId: process.env.BEDROCK_AGENT_ID || "ABCD1234EF", cognitoUserPoolId: process.env.COGNITO_USER_POOL_ID || "ap-northeast-1_XyZ123", cognitoClientId: process.env.COGNITO_CLIENT_ID || "1a2b3c4d5e6f7g8h9i0j", }; AIが「環境変数が設定されていない場合に備えて」と気を利かせて、フォールバック値を書いていたんです。 旧環境では、たまたまこのフォールバック値が指すリソースが存在していたので動いていた。でも新環境では別のAWSアカウントなので、当然そんなリソースは存在しない。だから動かない。 しかもエラーメッセージを見ても「リソースが見つかりません」としか出ないから、 環境変数の問題だと気づけなかった 。 なぜ1週間もかかったのか 正直に言います。 自分がコードをほとんど読まなかったから です。 Vibe Codingの快適さに甘えて、AIが生成したコードをちゃんと確認していませんでした。だから問題が起きたときに「どこを見ればいいか」がわからない。 Claude Codeにデバッグさせても、ピンポイントで原因に辿り着けない。結局、新旧環境の挙動の違いをCloudWatchログレベルで比較させて、やっと「あ、ここか」となりました。 Vibe Codingで楽をした分、トラブル時のツケを払わされた感じです。 引き継ぎ相手も困っていた 自分だけじゃなく、引き継ぎ相手も困っていました。 コード量が多くて、全体像を把握する時間が足りない どこが重要なコードなのかわからない ドキュメントもない 最終的にAIにアーキテクチャ図を生成させて、やっと自分でも全体像がなんとなくわかった状態でした。コードだけ渡されても、正直 自分でも説明できない 。 これは引き継ぎとして完全に失敗です。 教訓：Vibe Codingで引き継ぎを壊さないために この経験から得た教訓を共有します。 1. AIには必要最小限の仕事だけさせる 「あると便利かも」でコードを追加させない。依頼していない機能を勝手に実装されると、把握できないコードが増えるだけ。 2. Agent.md（CLAUDE.md）で余計なことをさせない制御 プロジェクトルールを明文化しておく。特に「やってはいけないこと」を書いておくのが重要。 3. コードレビューを徹底する AIが生成したコードであっても、人間によるレビューは不可欠です。これにより、不要なコードや潜在的な問題を早期に発見し、コードの品質を維持することができます。 <!-- ※ 以下はAIが生成した例示です。プロジェクトに応じてカスタマイズしてください。 --> # プロジェクトルール ## 環境変数 - 環境変数にフォールバック値（デフォルト値）を絶対に書かない - 環境変数が未設定の場合は明示的にエラーを出すこと - 環境変数の一覧は `.env.example` に記載し、常に最新化する ## コード規模 - 実装は必要最小限にする。「あると便利かも」で追加しない - 1ファイル300行を超えたら分割を検討する - 使われていないコードは即削除する ## ドキュメント - アーキテクチャ図（`docs/architecture.md`）を常に最新に保つ - 新しいAWSリソースを追加したら、必ずアーキテクチャ図を更新する - READMEのセットアップ手順は、新環境で動くことを前提に書く ## やってはいけないこと - ハードコードされた認証情報・リソースID - 「とりあえず動く」ための回避策（後で必ず負債になる） - 依頼されていない機能の追加 3. 環境変数はフォールバック値なしで即エラーにする 今回の問題を防ぐなら、こう書くべきでした： // ※ 以下はAIが生成した例示コードです。実際のコードとは異なります。 // config.ts const requireEnv = (key: string): string => { const value = process.env[key]; if (!value) { throw new Error(`環境変数 ${key} が設定されていません`); } return value; }; export const config = { dynamoTableName: requireEnv("DYNAMO_TABLE_NAME"), bedrockAgentId: requireEnv("BEDROCK_AGENT_ID"), cognitoUserPoolId: requireEnv("COGNITO_USER_POOL_ID"), cognitoClientId: requireEnv("COGNITO_CLIENT_ID"), }; これなら環境変数が未設定のとき、すぐにエラーで気づける。 4. ドキュメントを自動生成・自動更新する仕組みを作る コードだけでは引き継ぎできない。アーキテクチャ図やREADMEは必須。 できればコードの変更に合わせて自動更新される仕組みを作りたい。完璧は無理でも、「コードとドキュメントがズレている」状態は避けたい。 まとめ まとめ Vibe Codingは楽しいし、生産性も上がる。でも 引き継ぎ という観点では落とし穴がある。 AIが「気を利かせて」書いたコードが、別環境で問題を起こす 自分でコードを把握していないから、トラブル時に対応できない 引き継ぎ相手もコードを理解できない 100%コントロールするのは無理でも、できるだけ手綱を握っておく のが大事だと痛感しました。 Vibe Codingをやるなら： Agent.mdで「やってはいけないこと」を明文化する AIには最小限の仕事だけさせる ドキュメントは最初から用意しておく AIが生成したコードも必ず人間がレビューする この記事が、同じ轍を踏む人を一人でも減らせたら嬉しいです。

こんにちは。KINTOテクノロジーズのEngineering OfficeでAccessibility Advocateとして働いている辻勝利です。 今回は、去る1月15日に同チームの皆様向けに開催した「障害平等研修（Disability Equality Training）」についての開催報告をしたいと思います。 そもそも「障害平等研修」とはなにか、なぜEngineering Officeの有志向けに最初の研修を開催したのかなど、お話しできればと思います。 1. はじめに：なぜ「技術」の組織が「マインド」を学ぶのか アクセシビリティの分野に携わる中で、私はある「失敗」を多く目にしてきました。それは、アクセシビリティが「障害者のための特別な対応」と定義された瞬間、優先度が下がり、多忙を理由に見送られてしまうという現実です。 これを変えるには、手法（How）の前に、アクセシビリティを追求する「意義（Why）」を社内文化として根付かせることが不可欠です。昨年11月にKINTOテクノロジーズに入社して以来、私が「文化形成」を最重視しているのはそのためです。その第一歩として、まずは身近なEngineering Officeのメンバーを対象に「障害平等研修（DET: Disability Equality Training）」を実施しました。 2. 障害平等研修（DET）とは DETは1990年代のイギリスで誕生しました。日本でも「障害者差別解消法」の施行や、東京2020大会のボランティア研修に採用されるなど、世界標準のプログラムとなっています。 最大の特徴は、障害者自身がファシリテーターを務めること、そして「教わる」のではなく「参加者同士の議論」を通じて気づきを得ることです。今回は約1時間のダイジェスト版として、「障害とは何か？」「障害はどこにあるのか？」という本質的なテーマを深掘りしました。 3. 参加者の属性 今回はEngineering Officeを中心に、名古屋や福岡など各拠点から5名が室町オフィスに集結しました。普段リモートワークが多い私ですが、あえて対面形式を選んだのは、温度感のある深い対話の場を作りたかったからです。お菓子を囲み、リラックスした雰囲気の中で研修はスタートしました。 4. 研修の様子：問題を「発見」するプロセス 研修ではイラストやビデオを用い、日常に潜む「問題」を探し出しました。 印象的だったのは、参加者の皆さんがごく自然に、障害を「個人の問題」から「社会や環境の問題」へと転換して議論を進めていたことです。エンジニアリングに携わる方々らしく、目の前の事象を「解決すべき課題」として捉える姿勢が非常に頼もしく感じられました。 5. 心境・視点の変化：アンケートが語る「パラダイムシフト」 研修の前後で、参加者の「障害」に対する解釈は驚くほど変化しました。 最初は「心身の機能に関すること」や「それに伴って何かができないこと」という前提で話し始めていたメンバーが、ワークショップでの対話を重ねるうちに、自分たちの外側にある要因を含めた新たな視点で障害を捉え直そうとしている姿が印象的でした。 終了時には、参加者の口から「障害に対する考え方の前提がひっくり返った気がする」といった言葉が聞かれ、ファシリテーターとしてこの上なく手応えを感じた瞬間でした。 アンケートでも満足度・内容ともに10点満点中9〜10点という極めて高い評価をいただき、以下のような前向きな声をいただいています。 「本人と環境という、2つの問題に目線が広がりました」 「こういう考え方が一般常識になれば、世の中が変わると思う」 「ぜひ後半もやりたい。他の拠点やチームにも広めたい」 「議論を活発にするための心理的安全性についても検討していきたい」 6. 今後のアクション：誰もが「社会を変えるプレーヤー」に モビリティの分野において「障害」について深く掘り下げることは、これからの移動の在り方を考える上で避けては通れないテーマです。 研修を通じて私たちが得た最大の収穫は、アクセシビリティを「誰かのための特別な対応」ではなく、「身近なところにあり自分たちが解決できるかもしれない課題」として捉え直したことです。自分の仕事のどこにバリアがあり、どこに解決の可能性があるのか。その気づきこそが、文化を変える第一歩になります。 誰もが社会のバリアを取り除く「プレーヤー」であると実感できる職場。その先に、KINTOテクノロジーズが「すべての人にとって働きやすく、価値を提供できる場所」になる未来を目指し、この対話の輪を他拠点や他部署へも広げていきたいと思っています。

こんにちは。KINTOテクノロジーズ（KTC）でKINTOの中古車ECサイトのディレクターをしている かーびー です。 KINTO 中古車 とは、「KINTOの新車返却車両」の中から状態の良いクルマのみを、クルマのプロが厳選して提供する「高品質な中古車サブスクリプションサービス」です。 今回は、KINTOの中古車に関わる有志のメンバーで試験的に実施した「ユーザーインタビューわいわい会」の取り組みと、そこから得られた気づきや学びについてご紹介します。 「ユーザーインタビューわいわい会」とは？ 私たちは、ご契約いただいているお客様が、どのような点に魅力を感じているのかを深く理解するため、継続的にユーザーインタビューを実施しています。 ただ、インタビュー担当者のハイライトや要約だけでは、お客様の姿や言葉の裏にある「熱量」といった生の声を、インタビューに参加していないチームメンバーには十分に伝えきれない場面があります。 そこで、メンバーそれぞれが直接お客様の声に触れ、課題への解像度を揃えることで「チームの温度感をより高めたい！」と考えました。そこで試験的に実施したのが、ユーザーインタビューの録画動画をみんなで視聴し、ディスカッションする会です。 KINTOの中古車に関わる有志メンバー13名で実施 「ユーザーインタビューわいわい会」の概要 今回はお昼の時間帯を使っての実施だったため、視聴しながら参加できるようにランチもあわせて用意しました。 実際の流れ（約60分間） 今回はテスト実施として、以下の時間配分で行いました。 ユーザーインタビューの視聴：約35分 個人ワーク：約5分 テーブルごとに共有：約15分 全体振り返り：約5分 結果として、共有や振り返りの時間がかなりタイトになりました。 特にテーブル共有では、話が盛り上がったところで時間切れになる場面もあり、「もっと話したかった」という声も聞かれました。 意識したポイント 発言力やドメイン知識の差によって意見が偏らないよう、「まず一人で書く→その後に共有する」という流れを採用しました。 また、普段はお客様の行動データ（定量）を見ていますが、数字だけでは「なぜその行動をしたのか」までは分かりません。そこで今回は、データから立てた仮説を事前に配布し、インタビュー（定性）で検証する形をとりました。「定量では見えないこと」に自然と目が向くような設計を意識しています。 定量→定性で見えたこと（仮説検証の例） 例えば、あるお客様のデータからは「 車種Aを複数お気に入り登録 していたが、最終的に 車種Bで契約 した」という事実が見えていました。 仮説1： 納期や価格 を優先し、Bの車種に切り替えたのではないか？ 結果： インタビューを通じて、こちらは 概ね仮説通り であることが確認できました。 一方で、データだけでは読み解けなかった大きなギャップもありました。 仮説2： 初回訪問から数十時間で契約しているため、 納期最優先で即決 したのではないか？ 結果： 仮説は外れていました。 実際には、数ヶ月にわたって外部サイトで徹底的にリサーチを重ねた「熟考の末」の訪問でした。 真相： 納期も要素のひとつではありましたが、 最終的な決め手は「サービスとしての信頼性」 。納得感が醸成されたタイミングでサイトを訪れたため、結果として「即決」というデータとして現れていただけでした。 このように、定量データだけでは見えない「意思決定の背景」や「迷いのプロセス」が、生の声を聞くことで具体的に浮かび上がってきました。 「ユーザーインタビューわいわい会」を実施してみて ① お客様の判断の瞬間を共有できた 本会終了後のアンケートでは、 参加者全員から「印象に残った瞬間があった」という回答 が得られました。 たとえば、 「KINTOって、Webで申込完結・車両保険も月額に入ってこの価格なんですよね？」「想像していたより、含まれているものが多いですね」 といった発言があり、サービスの説明を受ける中で、想定していたよりもコストパフォーマンスが高いと感じた様子が率直に語られました。 さらに、トヨタの正規販売店による整備・メンテナンスが月額料金に含まれている点について、車両トラブル時にすぐ対応してもらえたというエピソードも挙がり、購入後の体験にも満足していることがうかがえました。 こうした一連の声から、中古車であっても「安心して使える体験」と価格のバランスが、意思決定において重要な価値として受け取られていることを直接確認でき、チームにとって確かな手応えにつながりました。 ② 次の仮説が自然と生まれた ユーザーインタビュー視聴後には、 車の知識レベルによって、選び方はどう違うのか？ コストパフォーマンスを、どの要素で評価しているのか？ 他社との比較は、どの程度行われているのか？ 契約前に家族とどのような会話をしているのか？ 「中古車」というワードにどのような印象を持っているのか？ といった 問いや気づき、仮説が60件以上 集まりました。 感想で終わるのではなく、次の仮説やアクションにつながる問いが、さまざまな職種のメンバーから自然に生まれたことは、実務につなげやすい状態をつくれたという意味でも、大きな収穫でした。 ③ チームに共通言語ができた 本会後の会議では、 「ユーザーインタビューのお客様も同じことをおっしゃっていましたが…」 といった会話が出るようになりました。 顧客像を共通の根拠として会話できる状態が生まれ、これを積み重ねていくことで、議論のスピードや精度も高まっていくのではないかと考えています。 参加者の声（一部抜粋） 「アンケートだけでは本質的なニーズや背景に十分に踏み込めない場合があると感じました。直接ヒアリングの機会を持つことで、課題の根底にある思いや具体的な状況をより深く理解できることに気づきました。」 次回に向けて 今回はテスト実施という位置づけで、60分という限られた時間の中で実施しました。取り組みとしての有用性を確認できた一方で、次回に向けて磨いていきたい点も見えてきました。 次回は、以下のような点を中心に改善を進めていく予定です。 ディスカッション時間の拡大 参加人数を増やし、より多様な視点を集める 「時間が足りなかった」という声は、それだけ共有したい気づきが多く生まれていたということでもあると感じています。この熱量を、次回の場づくりにつなげていけたらと思います。 「ユーザーインタビューわいわい会」からの気づき 今回の「わいわい会」を通じて、職種や視点が異なるチームで前提を揃えていくための、いくつかの気づきがありました。 共通言語と「翻訳」の存在 モビリティ業界という特性上、私たちのチームには多様な専門性を持つメンバーが集まっています。立場によって言葉の捉え方が異なるのは当然ですが、自分自身、どこかで 前職のような少人数チームでの「阿吽（あうん）の呼吸」 を前提にコミュニケーションを組み立てていた部分があったと、改めて気づかされました。 今回、大人数で対話をする中で気づいたのは、これまでは誰かが言葉のギャップを埋める「翻訳」を自然に担ってくれていたのではないか、ということです。チームの規模や多様性が増すほど、個人の属人的な「翻訳」に頼るのではなく、一次情報という「共通の土台」を仕組みとして提供することが重要になると実感しました。 「一次情報」が対話の質を変える 伝え方のスキルを磨くことも大切ですが、それ以上に 「同じ一次情報を共有すること」自体が、前提を揃えるうえで非常に有効 だと再確認しました。今回の「わいわい会」のように、ユーザーの声を「一緒に体験する」形を続けていくことで、以下のような効果を得られそうだと感じています。 解釈のズレを未然に防ぐ： 同じ体験を起点にすることを繰り返すことで、チーム内の前提の食い違いが起きにくくなる。 多角的な視点を仕組みとして取り入れる： 職種や背景の違いから、一人では気づけない観点が自然と集まる。 対話のハードルが下がる： 「あの時の、あのお客様のことば」という共通言語が増えていくため、その後の議論がスムーズになる。 こうした小さな積み重ねを大切にしながら、対話の輪を少しずつ広げていけたらと思います。 おわりに 今回の「ユーザーインタビューわいわい会」は、社内で進められている ユーザーファースト の取り組みとも、自然につながる実践でした。 ユーザー理解をチームにどう広げ、実務にどう落とし込んでいくか。その一つのヒントとして、この「わいわい会」の形も引き続き試していけたらと思います。 ユーザーファーストに関する全社的な取り組みについては、以下の記事でも紹介しています。ぜひあわせてご覧ください。 https://blog.kinto-technologies.com/posts/2025-12-11-userfirst2025/

はじめに こんにちは。 my route 開発部でバックエンドチームのリーダーをしている yf です。 my route 開発部では、昨年 7 月に組織体制が変わり、新しい形で開発を進めています。 その変化に備えて、6 月から少しずつ進めてきた取り組みが、 半年たった今、チームの空気や仕事の進め方に確かな変化をもたらしています。 この半年で扱ったテーマは約 40。 一つひとつは小さな改善ですが、積み重ねることで 「開発の役割」や「プロダクトとの向き合い方」が大きく変わってきました。 本記事では、私たちがどんなステップを踏み、 なぜその変化が起きたのかを、時系列[^1]で振り返ります。 この記事はこんな人向け 開発が「実装担当」に閉じてしまっていることに違和感がある方 仕様やスケジュールが決まった状態で渡ってきて、Why を理解しづらいと感じている方 プロダクト思考を持ちたいが、日々の開発で手応えを持てていない方 組織改善をしたいが、何から手を付ければいいかわからないリーダー・サブリーダー 「誰かを責める」のではなく、「構造を変える」アプローチを探している方 私たちが半年間かけて試行錯誤してきた取り組みが、 同じような悩みを持つチームのヒントになれば幸いです。 当時の状況と、なぜそうなっていたのか 取り組みを始める前、開発部には次のような状況がありました。 要件や仕様が、開発フェーズの後半で共有されることが多かった 開発期間が限られ、品質改善や振り返りに十分な時間を取れなかった スケジュールや設計の背景（Why）が、開発側に伝わりにくかった 結果として、実装を中心に進めざるを得ない進め方になっていた これは、特定の誰かの判断ミスというよりも、 "役割分担とプロセスの構造がそうさせていた状態" だったと振り返っています。 プロデューサーはプロダクトを良くしようとする責任感から、 設計やスケジュールをできるだけ具体化しようとしていました。 一方で、その分、開発に共有されるタイミングが遅くなり、 開発側には「How（どう作るか）」を中心とした情報が渡る構造になっていました。 その結果、 "なぜこの機能を作るのか（Why）を理解した上で改善提案を行う余地が少なくなり、" 開発が実装中心の役割に閉じてしまっていたのです。 この状況を変えるために、 私たちは "開発組織から、プロダクト組織へ" という 大きな方向転換に踏み出しました。 半年間の全体像 目的定義 → プロセス設計 → 運用定着 → 連携強化 → 品質と戦略 → 組織文化として定着 まず、私たちが向き合っていた「仕事の流れ」の変化を、Before / After で示します。 ■ 6 月 —— “目的と役割の再定義” 組織変革の起点 まず取り組んだのは、 “私たちはどこに向かうのか“ “チームリーダーは何を担うのか“ という意図合わせでした。 開発に関わる関係チームのリーダー全員（PDM・QA・バックエンド・モバイル）で、理想像の輪郭を描き直しました。 主なテーマ 独立プロダクト組織としての目的定義 リーダー役割の再整理 過渡期の案件対応 仕事の流れ図（AS-IS）の棚卸し チーム役割の再設計 会議体・Slack などコミュニケーション設計 この段階で、別の部である Engineering Office にも参画してもらいました。 開発部の中だけでは前提になっていた考えや、 見落としていたプロセスの歪みを、 第三者の視点から言語化・整理してもらえたことは、 その後の設計を進めるうえで大きな支えになりました。 6 月 あらためてひとこと - “まず揃えないと、何も始まらない” この時点では、具体的な施策よりも "前提が揃っていないまま進むことの危険性" を強く感じていました。 早く手を動かしたい気持ちを抑え、 あえて立ち止まって目的と役割を言語化したのは、 後戻りしないための投資だったと思っています。 ■ 7 月 —— “仕組みの再設計に着手” 新しい仕事の流れの原型ができた 6 月に定義した理想を、実際のプロセスに落とし込んだ月です。 スプリント導入（計画・中間・レビュー・レトロスペクティブ） チーム間連携会の常設 Jira運用ルールの再構築 ストーリーチケット作成基準の統一 Git ブランチ戦略の見直し リリースフロー整備 成果物レビューの仕組み化 問い合わせ・障害の暫定ルール化 “会議体・プロセスがゼロから設計されていくスピード感“ があり、 部全体の透明性が大きく向上しました。 7 月 あらためてひとこと - “理想を、現実の流れに落とす” 6月に描いた理想は、そのままでは机上の空論でした。 リーダとして意識したのは「誰がやっても迷わない仕組み」になっているか。 プロセスを設計することは、メンバーの思考コストを下げることだと実感した月でした。 ■ 8 月 —— “新プロセスの定着と運用強化” Jiraと仕事の流れが形になってきた 新プロセスの試験運用 新規案件でのトライアル導入 UI 定例、Slack などコミュニケーション基準化 問い合わせ・ツール改修フローの改善 ロードマップレビューの開始 プロセスが回り始めたことで、 “現場から自然と改善提案が出る状態“ が生まれはじめました。 8 月 あらためてひとこと - “仕組みは、使われて初めて意味を持つ” 新しいプロセスは、導入しただけでは根付きません。 この月は「守らせる」よりも "使ってみてどうだったかを聞く" ことに注力しました。 現場から改善案が出始めたとき、組織が一段階変わった感覚がありました。 ■ 9 月 —— “プロダクト思考と横断連携の強化” チーム間連携が日常化 ストーリー分割ワーク 役割を越えたアイデア提案の促進 リソースアサイン管理の透明化 AI 活用案件の相談 リリース承認ルートの改善 リーダー陣の視点が “「自分の領域」から「プロダクト全体」“へ 大きくシフトした月でした。 9 月あらためてひとこと - “役割を越えることを、許可する” プロダクト全体の話をするとき、役割を理由に遠慮が生まれる場面がありました。 リーダとして意識したのは、「それはあなたの領域じゃない」という空気を消すこと。 横断連携は、仕組みだけでなく心理的安全性があって初めて機能すると学びました。 ■ 10 月 —— “運用・リスク管理の高度化” 問い合わせ・障害・運用プロセスが進化 問い合わせ・障害フローの再整備 運用体制の検討 目的起点の進め方ワーク アジャイルトレーニング準備 他部門との連携強化 “リスクを未然に防ぐ動き” が自然と発生する組織へと変化しました。 10 月 あらためてひとこと - “問題が起きる前提で、組織をつくる” 問い合わせや障害は、ゼロにはできません。 だからこそ "起きたときにどう振る舞えるか" を考えるフェーズに入りました。 個人の頑張りに依存せず、組織として耐性を持つことを意識し始めた月です。 ■ 11 月 —— “品質・戦略・成長のフェーズへ” 技術とビジネスがつながり始めた スプリントへの QA 導入方針の確定 セキュリティ監査オーナーの役割整理 ポストモーテム文化の定着 UI/UX 改善の進め方刷新 フィールドワーク成果の共有 “案件をこなす組織” から “プロダクトを成長させる組織” へと進化。 11 月 あらためてひとこと - “技術は、ビジネスとつながってこそ価値になる” 品質やUXの議論が増えたことで、技術がプロダクト価値にどう貢献するかを 言葉にする機会が増えました。 リーダとしては、技術的な正しさと、事業としての判断をつなぐ役割を より強く意識するようになりました。 ■ 12 月 —— “半年の蓄積が組織文化に変わり始めた” 目的起点で動ける組織に UI/UX 改善の長期方針の確立 QA 導入プロセスの実運用 ロードマップレビューの定着 工程ごとのリードタイム測定開始 6 月に掲げた “自律したプロダクト組織になる” という目標が、実際の動きとして現れてきました。 半年で生まれた “4 つの変化” ① 情報の透明性 プロダクト全体の状態が誰にでも見えるようになった。 ② 早期リスク検知 問い合わせ・障害・運用課題が芽のうちに見つかるようになった。 ③ 横断連携の活性化 PDM・QA・バックエンド・モバイルが互いに提案しあう文化が育った。 ④ 再現性のあるプロセス “誰がやっても前に進む” 仕組みが整った。 12 月 あらためてひとこと - “文化は、後から気づくもの” 何か劇的なイベントがあったわけではありません。 ただ振り返ってみると、目的から考え、自然と連携し、改善を回す "当たり前の動き" が定着していました。 組織文化は、作ろうとして作るものではなく、 積み重ねの結果として生まれるのだと感じています。 もともとの課題は、どこまで変わったか 取り組みを始めた当初、私たちは 「開発が実装中心の役割に閉じてしまっている」という課題を抱えていました。 半年間の取り組みによって、 Why を共有したうえで議論できる場が増え スケジュールや設計の背景を前提に、改善提案が出るようになり 開発が「決められたものを作る」だけの立場ではなくなってきた といった変化が確かに生まれました。 一方で、 すべてが理想通りに解消されたわけではありません。 プロダクト全体の意思決定への関与や、 戦略レイヤーでの議論は、まだ発展途上です。 それでも、 「なぜやるのかを考えながら作る」ことが当たり前になり始めた という点で、 当初感じていた課題は、確実に別のフェーズへ進んだと感じています。 次の半年へ これからは、 “プロダクトをつくる組織“から“プロダクトを成長させる組織“ へさらに進化していきます。 グロースハック文化の定着 権限移譲と育成の体系化 プロダクト戦略の内製化 インシデント学習ループ強化 開発体制の継続アップデート 内部だけで議論すると主観に偏り、問題の本質を見誤ることがあります。 そのため今回は、部を横断して取り組めたことも私たちにとって大きな追い風となりました。 半年で大きく変化した組織が、次の半年でどこまで成長できるのか。 私自身、とても楽しみにしています。 さいごに my route 開発部では、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！ [^1]: 半年で扱った 40 のテーマを月別の代表例として抜粋しています。

はじめに こんにちは、2025年10月入社のr.tesakiです！ 本記事では、2025年10月入社のみなさまに入社直後の感想をお伺いし、まとめてみました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ S.N.  自己紹介 KINTO中古車開発Gのバックエンドエンジニアとして入社しました。室町オフィス勤務です。 最近映画館の近くに引っ越したので、映画館で映画を観るのにハマっています！ 所属チームの体制は？ KINTO中古車開発Gは、プロデュースチーム、フロントエンドチーム、バックエンドチームの3チーム体制です。 バックエンドチームは自分を含めて8名です。 現場の雰囲気はどんな感じ？ 出社した日にはチームメンバーと一緒にランチに行くなど賑やかな雰囲気です。 KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機： 大きなエンジニア組織＆物を扱うサービスに携わりたいと考えていたため。 入社前後のギャップ： ミーティングや社内イベントなどで他拠点の方とも関わることが想像よりも多く、会社としての一体感があって良いと感じています！ オフィスで気に入っているところ 室町オフィスは駅直結なので、天気を気にしなくて良いのが嬉しいです！ M.U.さん ⇒　S.N.さんへの質問 小学生の時の将来の夢（なりたい職業）は何でしたか？ 小学校の卒業アルバムの写真撮影でエプロンをつけた記憶があるので、料理人になりたかったんだと思います！ K.S.  自己紹介 酒とカラオケをこよなく愛するアラフィフ。自称元プロゲーマー。 所属チームの体制は？ コーポレートIT部所属。親会社のビッグプロジェクトに参画してシステムリプレースのリーダー。 現場の雰囲気はどんな感じ？ 個々が際立っていてオリジナリティーのある人たちがワイワイしている感じ。 KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機： エンジニアの報酬が高いし、役職定年ないし、バリバリ働けそうだから。 入社前後のギャップ： チームで働くというよりピンで活動することが多い気がする。意外に社長、副社長との距離が近いｗ オフィスで気に入っているところ 神保町オフィスは人が少なくて広々と使えるし、とても開放感があってよい！ S.N.さん ⇒　K.S.さんへの質問 一番好きなお酒を教えてください！ ビール🍺がサイコーです👌が、痛風が怖いので梅サワーで我慢してます🤷‍♂️ r.tesaki  自己紹介 オンプレのインフラエンジニアからスタートしてKTCではプラットフォーム開発部DBREグループのSREチームメンバーとして入社しました。Osaka Tech Lab所属です。 所属チームの体制は？ Database を専門とするDBREチームと、プロダクト全体を担うSREチームの2チームに分かれて活動してます。KINTOや他の業務システムの開発チームと一緒に活動することが多いです。 現場の雰囲気はどんな感じ？ Osaka Tech Labはチームを跨いだ一体感があって、他のチームメンバーは東京にいますが孤立感はなく賑やかに感じてます。 KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機: 組織横断であったり、プロダクト専任であったりと色々な形のSREに挑戦できそうだったため。 入社前後のギャップ: 聞いてた以上に東京へ行ける機会が多く、承認もスムーズに進むことです。各種イベント参加もしやすいです。 オフィスで気に入っているところ JR大阪駅の改札を出て目の前にオフィスビルの入口があるところ。 K.S.さん ⇒　r.tesakiさんへの質問 10億当たったら何に使う？ 猫を飼う人しか住めないマンションを立てて猫好きの楽園をつくる！ ぬー  自己紹介 プラットフォーム開発部 Cloud Infrastructure G に所属しています。KINTO 関連システムの AWS インフラの構築や保守運用を担当しています。 所属チームの体制は？ グループはインフラチーム、カイゼンチーム、ソリューションチームの3チーム体制で、同じインフラ領域でも別々の責務を担っています。 現場の雰囲気はどんな感じ？ メンバーの仲が良く、雑談も多いです。 KTCへ入社したときの入社動機や入社前後のギャップは？ プラットフォーム開発部はグループやチームがたくさんあり、思っていた以上に役割が細分化されていると感じました。 若手をリードしてほしいと言われて入社しましたが、今のところ(いい意味で)リードする必要性を感じないぐらい素晴らしいメンバーだと思います！ オフィスで気に入っているところ 神保町オフィスは近隣に飲食店が豊富で、おいしいお店が多いところ r.tesakiさん ⇒　ぬーさんへの質問 おすすめのキャンプグッズ教えてください！ 特にこれ！というグッズは無いのですが、SOTO というメーカーの製品はコンパクトなものが多いのでおすすめです！ キャンプをしていると荷物が増えてきて、少しでも物を減らしたり同じ用途でも小さいものにしたくなるので。 (といっても自分では持っていなくて、今後買いたいなと思っているところですｗ) U.V.  自己紹介 ビジネスディベロップメントGのU.V.です。 国内外のビジネス拡張を担当しております。 所属チームの体制は？ 5名で構成された、多国籍のチームです。 現場の雰囲気はどんな感じ？ マネジメントからの方針は明確ですが、各メンバーが自由に意見を述べ、自分の仕事に主体性を持って取り組めていると感じています。 KTCへ入社したときの入社動機や入社前後のギャップは？ オリエンテーションは分かりやすく、私が抱えていた疑問をすべて解消してくれました。 入社時点で有給休暇が付与されると伺い、とても驚きました。ありがとうございます。 毎月新しいプロジェクトが立ち上がり、仕事がとてもダイナミックで楽しんでいます。 オフィスで気に入っているところ オフィスは混雑しておらず、木製の家具がとても可愛らしいです。 ぬーさん ⇒　U.V.さんへの質問 日本に来た動機と、日本に来て驚いたことや変だなーと思うことがあれば教えてください！ 日本で留学生として過ごした時間がとても楽しく、自分の国とは大きく違う環境でキャリアを築きたいと思い、日本で働くことを決めました。 驚いたことの一つは、日本の方が電話でもお辞儀をすることです。 M.U.  自己紹介 モビリティプロダクト開発部で、販売店様との関係構築/プリセールスを担当しています 勤務先は今年開設されたばかりの福岡です 所属チームの体制は？ 4名体制（私以外は東京のオフィスがベース）で全国の販売店様を担当しています 現場の雰囲気はどんな感じ？ 福岡では皆で協力しながら、オフィスを運営しています 出張で来られる方が多いので、部署を超えて会話する機会が多いですね チームメンバーとは定期的にオンサイトでコミュニケーションを取っているので、リモートだからといって不自由は無いです KTCへ入社したときの入社動機や入社前後のギャップは？ 中規模Sierとスタートアップを経験したので、規模の大きな会社で新しいチャレンジをしてみたいと思ったからです 大きなギャップはなく、個々人のスキルが高くプロの集団だと感じました オフィスで気に入っているところ 勤務先の福岡テックラボは11月にオープンしたばかり！ 海が見渡せる開放感のある景色とおしゃれな内装で、出社したくなるオフィスです U.V.さん ⇒　M.U.さんへの質問 お仕事の中で、AI をどのように活用しているのか、興味深い取り組みがあれば教えていただけますか。 主に調査や資料作成など一般的な使い方です 情報をキャッチアップする際にコパイロットだと、社外情報＋社内資料も提案してくれるのが素敵ですね 販売店様の情報を調査する等であればGeminiの方が優秀だと感じています さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

この記事は KINTO テクノロジーズ Advent Calendar 2025 の 25 日目の記事です 🎅🎄 はじめに こんにちは！ KINTO 開発部 KINTO バックエンド開発 G マスターメンテナンスツール開発チーム、技術広報 G 兼務、Osaka Tech Lab 所属の high-g（ @high_g_engineer ）です。フロントエンドエンジニアをやっています。 現在開発中のプロジェクトでは、RC 版の頃から React Compiler を導入しており、約 8 ヶ月が経ちました。 導入によって useMemo や useCallback を書かなくても自動でメモ化されるため、メモ化を意識する必要がなくなり、開発体験は向上しました。 しかし、実際にどの程度メモ化が正しく行われているのか、パフォーマンスにどれくらいの影響があるのかは、詳しく検証できていませんでした。 そこで本記事では、React Compiler の有効時の挙動や、有効時と無効時のパフォーマンス比較を検証してみることにしました。 React Compiler とは https://ja.react.dev/learn/react-compiler/introduction React Compiler は、ビルド時に自動的にメモ化を行うことで React アプリを最適化するツールです。 そのため、React Compiler を導入すれば、 useMemo や useCallback 、 React.memo などを手動で書く必要がなくなります。 最初の安定版（v1.0）は 2025 年 10 月 7 日にリリースされ、この記事が執筆された時点で約 2 か月半が経過しています。 安定版リリースまでの経緯は以下の通りです。 2023 年 3 月 - 「React Forget」として開発、Meta 社内の限定的な領域で production 利用開始 2023 年 10 月 - React Advanced Conference 2023 で「React Forget」として公開発表 2024 年 2 月 - instagram 全体で production 展開完了、Meta 社内の他サービスへ展開、OSS 化準備と発表 2024 年 5 月 - React Conf 2024 で experimental release を発表 2024 年 10 月 21 日 - Beta release を公開 2025 年 4 月 21 日 - Release Candidate (RC) を公開 2025 年 10 月 7 日 - v1.0 安定版リリース React Compiler の設定方法 Vite と React 19 を使用した環境での React Compiler の設定方法を紹介します。 1. パッケージのインストール pnpm add -D babel-plugin-react-compiler 2. vite.config.ts の設定 @vitejs/plugin-react の babel オプションに babel-plugin-react-compiler を追加します。 import react from "@vitejs/plugin-react"; import { defineConfig } from "vite"; // 設定オプション const ReactCompilerConfig = { /* ... */ }; export default defineConfig({ plugins: [ react({ babel: { plugins: [["babel-plugin-react-compiler", ReactCompilerConfig]], }, }), ], }); これだけで設定は完了です。後はビルド時に React Compiler が自動的にコードを解析し、必要な箇所にメモ化を適用してくれます。 React Compiler の設定オプションに関しては、本記事では説明を割愛します。 特に設定しなくても動作しますが、詳細を知りたい方は以下を参照してください。 https://ja.react.dev/reference/react-compiler/configuration ベンチマーク対象の React アプリ 実際の開発プロジェクトで検証を試みましたが、使用しているライブラリに既にメモ化されたコンポーネントが多く含まれていて、純粋な比較が困難だったので、ベンチマーク専用のプロジェクトを作成しました。 ヘッダー、サイドメニュー、メインコンテンツのエリアで構成され、初期表示時の合計コンポーネント数は約 100 個です。 最初に、React Compiler が無効の状態で、React Dev Tools でメモ化の状況を確認していきます。 Components タブを見ると、メモ化されている場合に表示される「Memo」のラベルが一切ないことがわかります。 次に、React Dev Tools の設定で Highlight updates when components render にチェックを入れて、上位にあるボタンコンポーネントをクリックし再レンダリングの様子を確認すると、本来再レンダリングが不要な子孫コンポーネントにも再レンダリングが発生していることが分かります。 React Compiler のメモ化の挙動 React Compiler を有効にして開発サーバーを立ち上げ、同じアプリがメモ化されているかを確認します。 React Dev Tools の Components タブを確認すると、「Memo」のラベルが数多く表示されていることが分かります。 同様に、上位にあるボタンコンポーネントをクリックし、React Dev Tools で再レンダリングの状態を確認すると、再レンダリングが必要最小限に抑えられていることが分かります。 React Compiler のパフォーマンスベンチマーク ここからは、React Compiler によるパフォーマンスの差を React Dev Tools の Profiler を用いて検証していきます。 検証では、下記の赤枠のボタンを約 1 秒間隔で 10 回連続クリックした際の、レンダリング時間の比較を行いました。 このボタンはメインコンテンツの最上位に配置されているため、クリック時に多くの子孫コンポーネントへ再レンダリングの影響が波及します。 React Compiler 無効時（メモ化なし） 計測データ 1回目: 29ms 2回目: 34.5ms 3回目: 36.1ms 4回目: 33.9ms 5回目: 36.3ms 6回目: 17.6ms 7回目: 35.1ms 8回目: 32.1ms 9回目: 33.3ms 10回目: 36.8ms 平均レンダリング時間 32.5ms Flamegraph を見ると、すべての子孫コンポーネントがレンダリングされていることが分かります。また、MainContents 以外にもレンダリング時間が長いコンポーネント（黄色やオレンジ色で表示）が存在し、本来不要な再レンダリングが発生していることが確認できます。 React Compiler 有効時（メモ化あり） 計測データ 1回目: 11.1ms 2回目: 12.1ms 3回目: 12.2ms 4回目: 12.1ms 5回目: 12.1ms 6回目: 12.1ms 7回目: 12.1ms 8回目: 12.0ms 9回目: 12.0ms 10回目: 12.6ms 平均レンダリング時間 12.0ms Flamegraph を見ると、グレーの斜線で表示されているコンポーネントが多数確認でき、再レンダリングが必要最小限に抑えられていることが分かります。 パフォーマンス改善の結果 React Compiler 無効時 React Compiler 有効時 改善結果 平均レンダリング時間 32.5ms 12.0ms 約 2.7 倍高速化 React Compiler を有効にしただけで、非常に大きなパフォーマンス改善ができていることが確認できました。 今回はメモ化を全く行っていないプロジェクトとの比較のため、すべてのケースで同様の改善が見込めるわけではありませんが、導入効果は十分に期待できます。 懸念点 ライブラリとの相性 現在開発中のプロジェクトでは TanStack Table を利用しています。TanStack Table は新しい参照を意図的に生成することで再レンダリングをトリガーする設計のため、React Compiler によるメモ化が適用されると、再レンダリングが発生せず意図しない挙動を引き起こす可能性があります。 この問題に対しては、 "use no memo" ディレクティブを追加して部分的に React Compiler を無効化することで対応が可能です。 function TableComponent() { "use no memo"; const table = useReactTable({ data, columns, getCoreRowModel: getCoreRowModel(), }); return ( <table> {/* TanStack Table の参照変化に依存する処理 */} </table> ); } react-hook-form など、同様に参照の変化に依存するライブラリを利用する場合は、要所で "use no memo" の記述が必要になるため、導入時にはご注意ください。 ビルド速度低下、ビルドファイルサイズ上昇 React Compiler を導入すると、再レンダリング時のパフォーマンスは向上しますが、メモ化のためのコードが追加されるため、ビルド速度やファイルサイズに多少影響が出ます。その結果、初回読み込みが少し遅くなる可能性があります。 React Compiler 無効時のビルド結果 ビルド時間: 64ms ファイルサイズ: 232KB React Compiler 有効時のビルド結果 ビルド時間: 556ms ファイルサイズ: 248KB まとめ 今回は React Compiler を有効にしたときのメモ化に関する挙動の確認と、パフォーマンスにどれくらい影響があるのかを検証してみました。 結果として、メモ化が正しく動作し、そのおかげでパフォーマンス改善も十分に期待できることが分かりました。 ただし、いくつか注意点もあります。 参照の変化に依存するライブラリを使用する場合は、 "use no memo" で部分的に無効化が必要になることがあります。また、メモ化のコードが追加される分、ビルド速度やファイルサイズには多少影響が出ます。 とはいえ、これらは対処可能な範囲ですし、パフォーマンス改善だけでなくメモ化を意識しなくて済むというメリットは非常に大きいです。React Compiler の導入を迷われている方は、ぜひ試してみてください。 最後まで読んでいただきありがとうございました。 参考記事 https://ja.react.dev/learn/react-compiler/introduction https://ja.react.dev/reference/react-compiler/configuration https://reactadvanced.com/2023/ https://conf2024.react.dev/ https://react.dev/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023 https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024 https://react.dev/blog/2025/10/07/react-compiler-1 https://github.com/TanStack/table/issues/5567

こんにちは！KINTOテクノロジーズのクリエイティブGでデザイナーをしているmayuです。 今回は、技術書典の表紙制作の過程をご紹介したいと思います。 Midjourneyなどの生成AIツールを活用しているので、「 ノンデザイナーでもプロ並みの制作ができる？！ 」のがミソです。 デザイナーの方も、そうでない方もぜひご覧ください！ 技術書典用の表紙デザインを依頼された ある日、エンジニアのうえはらさんから 「KINTOテクノロジーズ(KTC)の有志エンジニアによる技術書を技術書典に出展したいので、表紙デザインを作ってほしい」 という依頼を受けました。 今回はクリエイティブGのデザイナーmomoiさんの提案で 「デザイナーを集めてライブペインティング方式で作成するのはどうか？」 ということで、ライブペインティングイベント内での制作が決定しました！ 技術書典ってなに？ 技術書典についてはうえはらさんが書いてくださった記事があるのでこちらをご覧ください。 https://blog.kinto-technologies.com/posts/2025-12-12-techbookfest19-report/ ライブペインティングってなに？ ライブペインティングについてはmomoiさんが書いてくださった記事があるのでこちらをご覧ください。 https://blog.kinto-technologies.com/posts/2025-12-24-ai-live-painting/ どうやって作ったか ざっくり作り方を説明すると、 1. お題をChatGPTにインプットさせる 2. ChatGPTにプロンプトを書いてもらう 3. Midjourneyで画像を生成する 4. Midjourneyで解像度UP & Photoshopで微修正する 5. illustratorで入稿データを作成する の5ステップです！ それぞれ紐解いていきますね。 1. お題をChatGPTにインプットさせる 今回のお題はこちらでした。 お題は事前に知らされていなかったので、正直「ざっくりしたお題だな…」と思い最初は全くイメージが浮かびませんでした。笑 2. ChatGPTにプロンプトを書いてもらう まずは、私の相棒ChatGPTにお題をインプットして、アイデア出しをしてもらうことにしました。 ひとまず、プロンプトを出してくれたのでこれをMidjourneyに入力していきます。 3. Midjourneyで画像を生成する 一回目の生成結果はこんな感じ！ るぴあは事前に配布されていた素材を Omni-Reference で読み込ませ、一貫性を保っています。 Omni-Referenceについてはmomoiさんが詳しく書いてくださっているのでこちらの記事をご覧ください。 https://blog.kinto-technologies.com/posts/2025-06-13-omni-reference/ ここまでやって、なんとなく世界観のイメージは湧いてきました。 でも、るぴあが棒立ちで動きがないので何か違うなーって感じ… 「どんなポーズがいいか？」とChatGPTに相談してみました。 さすがチャッピー！！かなり具体的でこれならイメージに合うものが作れそう！ それぞれのポーズをプロンプトに落とし込んでもらいました。 これを、もう一度Midourneyで生成してみます。 なかなかいい感じになりました！ 先ほどの棒立ちるぴあと比べると、「未来感」が増した気がします。 ただ、表紙の上部にはタイトルを入れる予定なので、これだと頭と文字が被ってしまいそうなんですよね… どうしよう…と考えた結果、 座らせることにしました！笑 (るぴあを座らせるようChatGPTにプロンプトを書いてもらいました) これなら画像の上部が空くので、タイトルも問題なく入りそうです。 何回か作成すると、かなりしっくり来る画像が生成されました！！ こちらです！ まさに私が求めていた「先進的で、モビリティ感のある画像」が生成されました！ 画像の上部もいい感じに空いているので、タイトルもきちんと収まりそうです。 ここから微修正は入れますが、ベースのデザインはこれで決定しました。 4. Midjourneyで解像度UP & Photoshopで微修正する ライブペインティングイベント内では時間制限があったため、先ほど生成した画像をそのまま提出したのですが、ありがたいことに依頼者票・オーディエンス票ともに1位に選んでいただき、晴れて表紙デビューが決定しました！！！ となると、先ほどの画像を表紙用に綺麗に整えていく必要があります。 ここからはMidjourneyとAdobeのPhotoshopを使って画像を修正していきます。 まずは、Midjourneyを使って解像度を上げていきます。 やり方はとても簡単で、画像を開いて右下の 「Creation Actions」→「Upscale」→「Subtle」を一回クリックするだけ です。 (隣にある「Criative」は、今回は元の画像を保持したいので使いませんでしたが、ディティールを加えてクオリティアップを目指すならこちらもおすすめです！) この操作により画質は保ったまま「 896px × 1,344px 」から「 1792px × 2,688px 」と、2倍の解像度になりました！ 次に、Photoshopで微修正をしていきます。 気になるのはこの辺ですね。 るぴあのヘッドホンに描かれている∞などのマーク 左下の暗号ぽいもの Photoshopで簡単に消していきたいと思います。 なげなわツールで不要な部分を囲ったら、「 生成塗りつぶし 」をクリックします。(※プロンプトは無しでOK) 綺麗に消えました！ 左下部分も同様の操作を行っていきます。 自然に馴染みました！ これで画像が仕上がったので、あとは入稿データを作成していきます。 5. illustratorで入稿データを作成する こちらが入稿データです！ タイトルなど付け足して背表紙と裏表紙も作成したら完成です。 制作を終えて 制作を終えて感じたのは、AIのおかげでノンデザイナーでも高品質なビジュアルを作れるハードルが格段に下がったということです。 今回の表紙制作でも、ChatGPTでのアイデア出しやMidjourneyでの画像生成によって、ゼロから何かを生み出す負荷が大きく減りました。 その一方で、「何がいい」「何が悪い」の判断や、細かな世界観の調整など、AIだけでは完結しない部分も多くあります。 だからこそ、AIの力を借りつつ、人間が持つ感性を利用して方向性を選択することが重要だとも改めて感じました。 私は今年からAIプロジェクトメンバーとして携わってきて、さまざまなツールを使う中で、少しずつ「 AIへの正しい頼り方 」がわかってきた実感があります。 AIはまだ完全ではなく、人間に置き換わることはできませんが、高いクリエイティビティを持っていて、私にとって仕事に欠かせない存在になっています。 これからも、AIを心強いパートナーとして、うまく協業しながら制作に向き合っていきたいと思っています。 最後までお読みいただき、ありがとうございました！

KINTOテクノロジーズ（KTC）の景山です！ 年末恒例となりますが、2025年の振り返りと、来る2026年の展望について書きたいと思います。 2025年の振り返り：実装とカルチャーへの定着 2025年の年初、私は「AIファースト」と「リリースファースト（最短リリース）」という2つのテーマを掲げました。 https://blog.kinto-technologies.com/posts/2024-12-25-LookBack2024/ 1. AIファースト：実装の年 世の中的にも生成AIの実装が当たり前となった2025年、KTCでも以下の3点を推進してきました。 すべてのプロダクトへのAIインテグレート AIプロダクトを多く開発する 販売店やトヨタグループにおけるAI活用のドライバーとなる この1年で、社員のみなさんのマインドは劇的に変わりました。私の想像を超えるスピードで変化が進み、KTCがグループ内でもAI活用の先頭集団にいられたのは、みなさんの真剣な取り組みのおかげです。本当にありがとうございました！ 2. リリースファースト：カルチャーへの浸透 こちらはテクニカルな施策というよりも、「プロダクト開発の文化」として組織に深く根付きつつあります。「何を作るか」だけでなく「いかに速く届けるか」。この意識が、私の想定を軽々と飛び越え、みなさんの手によって現場の当たり前になりつつあることに頼もしさを感じています。 2026年の展望：自律と拡張の年 テクノロジー業界の潮流は、「対話するAI」から「行動するAI」へと急速にシフトしています。 この波を捉えるために、2026年は以下の2つのファーストに注力します。 1. Agentファースト（Agentic AI） 2025年までのAIは、人間が指示を出して答えをもらう「賢いチャットボット」が主流でした。しかし、昨今の技術トレンドは、複雑な推論を行い、自律的にタスクを完遂する「AI Agent」へと完全に移行しています。 これまでのAI活用は「個人の作業補助」に留まりがちで、組織全体の効率化には限界がありました。しかし、Agentは違います。抽象的な目的を与えれば、AI自らがタスクを分解し、ツールを操作し、人間のようにアクションを実行します。 KTCでも一部の部署でAgent活用が始まっていますが、2026年はこれを全社展開します。 CX変革 ：Web/App上で、コンシェルジュのように振る舞うAI Ops変革 ：運用・業務プロセスを自律的に回すAI Sales変革 ：クルマの販売プロセスそのものを再発明するAI 世の中が「AIを使う」から「AIに任せる」へと変わる今、全部署でAgentを生み出し、組織の生産性を爆発的に高めていきましょう。 2. AIエンジニアリングファースト（AI-Native Dev） ソフトウェア開発の世界では今、GitHub Copilot WorkspaceやKiro、Cursor、Claude CodeのようなAIネイティブな開発環境が標準になりつつあります。「コードを書く」という行為そのものの定義が変わろうとしているのです。 この変化は、これまでの技術革新とは比較にならないスピードで進んでいます。古いやり方に固執すれば、あっという間に陳腐化します。しかし逆に言えば、 「AIエンジニアリング」を武器にすれば、職種の壁を超えられる ということです。 企画、要件定義、設計、実装。AIが実装をサポートしてくれる今、PdMやPjMといった職種の方々も、従来はエンジニア領域とされていた仕事まで拡張できるチャンスです。会社は最新の武器（ツール・環境）を惜しみなく提供します。一人ひとりが「AIネイティブ」な視点でプロセスを再構築し、開発のあり方を抜本的に変えていきましょう。 KTCの揺るぎない「基本的価値」 技術トレンドがいかに変わろうとも、KTCの競争力の根幹となる価値観は変わりません。 インテンシティ（MoveFast・OwnerShip） リリースファースト ユーザーファースト これらの価値はKTCの各人により構成され、KTCが変化の激しい時代を生き抜くための基礎力です。会社としても支援しますが、何よりみなさん自身の実践にかかっています。引き続き、徹底していきましょう。 KTCの強み、優位性：Vertical AIへの挑戦 汎用的なAIモデルは一般化し、世界中の誰もが使えるようになりました。では、KTCはどこで勝つのか。それは「ドメイン特化（Vertical）戦略」です。 AI (Agent) クラウド ドメイン知識 & グロースノウハウ AI×クラウドの技術力は前提条件です。ここは進化が速く、常に最先端をキャッチアップし続ける危機感が必要です。 その上で、我々には「トヨタグループのビジネス資産」があります。コネクティッドデータ、車両販売の知見、リアルな顧客接点。これらは他社が簡単に模倣できない資産です。 「AI×クラウド」というグローバルな武器で、「モビリティ」という独自の領域を深掘りする 。業務知識を蓄え、それをAIで価値に変換するサイクルを回すことこそが、KTCだけの強みになります。 最後に 2026年は、技術の進化がさらに加速し、社会実装のフェーズも一段階上がります。変化を恐れず、むしろその先頭に立つ気概を持って、一人ひとりがアップデートしていきましょう！

はじめに この記事は New Relic Advent Calendar 2025 の24日目の記事です。 こんにちは、SREチームの おさない です。本記事では 先日発表 されたNew Relic MCPサーバーをSlackから利用できるようにする方法について紹介します。 MCPサーバー自体はClaudeなどの対話型AIやCodex, Kiroなどのコーディングエージェントなど、さまざまなインターフェースで利用することができますが、Slackというインターフェースで使えるようにすることで、New Relicのデータ利活用の幅をさらに広げられると感じています。 構成図 今回は以下のような構成でSlackからNew Relic MCPを利用します。 今回作成する構成図 SlackでBotにメンションして質問することで、回答に必要な情報をNew Relic MCPを使って取得してスレッドに返信してくれます。 構築手順 :::message 本記事ではSlackからNew Relicのデータにアクセスできるようにするために最小限の内容を紹介しています。以下のような要素については省略していますので、必要に応じて対応してください。 システムプロンプトのチューニング New Relicのアカウントが複数ある場合、どのアカウントから情報を探しますか？といった返答になりがちなので、システムプロンプトなどで「利用なアカウントから順番に調査してください。」といった文言を入れると動くようになりました。 セキュリティ面の対策 今回紹介する構成はユーザーのインプットをそのまま伝えているため、入力・出力内容のガードレールを設けることをオススメします。 また、IAM Roleの権限も必要最小限の設定にすることをオススメします。 会話履歴の保持 今回の構成では会話履歴を保持しておらず、単発でのやり取りになります。 ::: New Relic APIキーの発行 New Relicの API Keys のページに遷移して、 Create a key ボタンを押下します。 Key Typeは User を選択して作成し、発行されたAPIキーを控えておきます。 Slack Appの作成と設定 - その1 まずはSlack Appを作成します。 Slack Appの作成方法についてはさまざまな記事があるため詳細な説明は省きますが、 こちら から From scratch でSlack Appを作成してください。 作成したら OAuth & Permissions のページに遷移し、Bot Token Scopesに chat:write の権限を追加します。 そして Install App から対象のSlackワークスペースにインストールし、発行された Bot User OAuth Token を控えておきます。 アプリケーションの構築 今回は AWS SAM と Strands Agents を使って構築します。私が構築した際のSAM CLIのバージョンは1.149.0でした。 以下にtemplate.yamlとそれぞれのLambda関数のコード、requirements.txtを記載します。 :::details template.yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Globals: Function: Timeout: 120 Resources: SlackEventHandlerFunction: Type: AWS::Serverless::Function Properties: FunctionName: slack-event-handler-function CodeUri: src/ Handler: slack_event_handler.lambda_handler Runtime: python3.14 Role: !GetAtt SlackEventHandlerFunctionRole.Arn SnapStart: ApplyOn: PublishedVersions AutoPublishAlias: SnapStart Architectures: - x86_64 Events: NewRelicBot: Type: Api Properties: Path: /event Method: post Environment: Variables: SQS_QUEUE_URL: !GetAtt SlackMessageSQS.QueueUrl SlackEventHandlerFunctionPermission: Type: AWS::Lambda::Permission Properties: Action: lambda:InvokeFunction FunctionName: !Ref SlackEventHandlerFunction Principal: apigateway.amazonaws.com SlackEventHandlerFunctionRole: Type: AWS::IAM::Role Properties: RoleName: slack-event-handler-function-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole - arn:aws:iam::aws:policy/AmazonSQSFullAccess SlackAIExecutorFunction: Type: AWS::Serverless::Function Properties: FunctionName: slack-ai-executor-function CodeUri: src/ Handler: slack_ai_executor.lambda_handler Runtime: python3.14 MemorySize: 256 Role: !GetAtt SlackAIExecutorFunctionRole.Arn Architectures: - x86_64 Events: SlackMessageSQS: Type: SQS Properties: Queue: !GetAtt SlackMessageSQS.Arn BatchSize: 1 Enabled: true Environment: Variables: NEW_RELIC_API_KEY: '' # 発行したNew Relic APIキーを設定 SLACK_BOT_TOKEN: '' # 発行したSlack Bot User OAuth Tokenを設定 SlackAIExecutorFunctionRole: Type: AWS::IAM::Role Properties: RoleName: slack-ai-executor-function-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole - arn:aws:iam::aws:policy/service-role/AWSLambdaSQSQueueExecutionRole - arn:aws:iam::aws:policy/AmazonBedrockFullAccess SlackMessageSQS: Type: AWS::SQS::Queue Properties: QueueName: slack-message-sqs.fifo FifoQueue: true VisibilityTimeout: 180 MessageRetentionPeriod: 600 ContentBasedDeduplication: true DeduplicationScope: messageGroup RedrivePolicy: deadLetterTargetArn: !GetAtt SlackMessageDLQ.Arn maxReceiveCount: 2 SlackMessageDLQ: Type: AWS::SQS::Queue Properties: QueueName: slack-message-dlq.fifo FifoQueue: true VisibilityTimeout: 180 MessageRetentionPeriod: 604800 ※ NEW_RELIC_API_KEY, SLACK_BOT_TOKENは必要に応じてパラメータストアから取得するなどの方法で設定してください。 ::: :::details slack_event_handler.py import json import boto3 import hashlib import os sqs = boto3.client('sqs') queue_url = os.environ.get('SQS_QUEUE_URL') def lambda_handler(event, context): body = json.loads(event['body']) if body.get('challenge') is not None: challenge = body['challenge'] return response('200', challenge) if body['event'].get('edited') is not None: return response('200', 'edited event ignored') if body['event']['type'] == 'app_mention': ts = body['event']['ts'] channel = body['event']['channel'] thread_ts = body['event'].get('thread_ts') text = body['event'].get('text') if text is None: return response('200', 'no text field') payload = { 'text': text, 'channel': channel, 'ts': thread_ts if thread_ts is not None else ts, } sqs.send_message( QueueUrl=queue_url, MessageBody=json.dumps(payload), MessageGroupId=channel, MessageDeduplicationId=hashlib.md5(text.encode()).hexdigest() ) return response('200', 'ok') def response(status_code, body): return { 'statusCode': status_code, 'body': body, 'headers': { 'Content-Type': 'text/plain', }, } 多重起動を防ぐために、同じ文言を送信した場合はSQSの重複排除機能によりメッセージが破棄されるようにしています textには <@U12345678> のようにSlack AppのメンバーIDが含まれるため、SQSにメッセージを送信する前に必要に応じてトリミング処理を追加してください。 ::: :::details slack_ai_executor.py import json import os from contextlib import asynccontextmanager from mcp.client.streamable_http import streamable_http_client, create_mcp_http_client from strands.tools.mcp.mcp_client import MCPClient from strands import Agent from strands.models import BedrockModel from slack_sdk import WebClient SYSTEM_PROMPT = """ あなたはNew Relicのデータを駆使して開発者をサポートする優秀なエンジニアです。 """ @asynccontextmanager async def _nr_transport(): async with create_mcp_http_client( headers={ "api-key": os.environ.get('NEW_RELIC_API_KEY'), "include-tags": "discovery,alerting,data-access,incident-response,performance-analytics,advanced-analysis", } ) as http_client: async with streamable_http_client( url="https://mcp.newrelic.com/mcp/", http_client=http_client, terminate_on_close=True, ) as streams: yield streams nr_mcp_client = MCPClient(_nr_transport) slack_client = WebClient(token=os.environ.get('SLACK_BOT_TOKEN')) model_id = "jp.anthropic.claude-sonnet-4-5-20250929-v1:0" def lambda_handler(event, context): body = json.loads(event['Records'][0]['body']) text = body['text'] channel = body['channel'] ts = body['ts'] with nr_mcp_client: tools = nr_mcp_client.list_tools_sync() model = BedrockModel(model_id=model_id, region_name='ap-northeast-1', temperature=0) agent = Agent(system_prompt=SYSTEM_PROMPT, tools=tools, model=model) response = agent(text) post_response = slack_client.chat_postMessage(channel=channel, thread_ts=ts, text=str(response)) if post_response['ok']: return True else: return False ::: :::details requirements.txt annotated-types==0.7.0 anyio==4.12.0 attrs==25.4.0 boto3==1.42.13 botocore==1.42.13 certifi==2025.11.12 cffi==2.0.0 click==8.3.1 cryptography==46.0.3 docstring_parser==0.17.0 h11==0.16.0 httpcore==1.0.9 httpx==0.28.1 httpx-sse==0.4.3 idna==3.11 importlib_metadata==8.7.0 jmespath==1.0.1 jsonschema==4.25.1 jsonschema-specifications==2025.9.1 mcp==1.24.0 opentelemetry-api==1.39.1 opentelemetry-instrumentation==0.60b1 opentelemetry-instrumentation-threading==0.60b1 opentelemetry-sdk==1.39.1 opentelemetry-semantic-conventions==0.60b1 packaging==25.0 pycparser==2.23 pydantic==2.12.5 pydantic-settings==2.12.0 pydantic_core==2.41.5 PyJWT==2.10.1 python-dateutil==2.9.0.post0 python-dotenv==1.2.1 python-multipart==0.0.21 referencing==0.37.0 rpds-py==0.30.0 s3transfer==0.16.0 six==1.17.0 slack_sdk==3.39.0 sse-starlette==3.0.4 starlette==0.50.0 strands-agents==1.20.0 typing-inspection==0.4.2 typing_extensions==4.15.0 urllib3==2.6.2 uvicorn==0.38.0 watchdog==6.0.0 wrapt==1.17.3 zipp==3.23.0 ※仮想環境でslack_sdkとstrands-agentsをインストールしてpip freezeしたもの ::: この内容でsam buildおよびsam deployを実行してデプロイします。 デプロイしたらAWSコンソールから作成されたAPI Gatewayのステージを確認し、作成したエンドポイントのURLを控えておきます。 例： https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod/event Slack Appの設定 - その2 先ほど作成したSlack Appの設定画面に戻り、 Event Subscriptions のページに遷移します。 Enable Events をONにして、Request URLに先ほど控えたAPI GatewayのエンドポイントURLを設定 Verifiedと表示されればOKです Subscribe to bot eventsの Add Bot User Event から app_mention を追加して保存 OAuth & Permissions のBot Token Scopesに app_mentions:read の権限が自動で追加されます ※変更を保存したら、再度Slackワークスペースにインストールしてください 動作確認 以上で構築は完了です！ Slackの任意のチャンネルに作成したSlack Appを追加してメンションを飛ばしてみましょう。質問内容にもよりますが、1分程度で返信がくるはずです。 Slackでの動作イメージ :::message レスポンスのフォーマットがSlackのフォーマットに最適化されていないため、場合によっては見づらい表示になる可能性があります。 私は以下のような方法でSlackフォーマット(のよう)に変換してからポストしています。 def convert_to_slack_format(text: str) -> str: # 太字 text = text.replace("**", "*") # 取り消し線 text = text.replace("~~", "~") # 冒頭に - が付いている場合 text = re.sub(r'^([ ]*)-', r'\1•', text) # 改行の後に --- が付いている場合は削除 text = re.sub(r'\n---+\n', '\n', text) # 改行の後に - が付いている場合 text = re.sub(r'(\n[ ]*)-', r'\1•', text) return text ::: MCPの機能は New Relic MCP ツールリファレンス で確認できます。ツールを組み合わせることでさまざまな活用ができそうです。 日頃ダッシュボードで確認している項目をSlack Reminderで定期的にBotにメンションして、要約してもらう アラート発生時のメッセージでBotをメンションに含めることで自動で一次調査させる 特定のセッショントレースIDでのユーザーの行動をまとめてレポートを作成させる おわりに New Relic MCPサーバーは本記事執筆時点ではPublic Previewの段階ですが、十分に実用的なレベルで利用でき、今後のアップデートが非常に楽しみです！ また、この仕組みはNew RelicのMCPサーバーに限らず、他のMCPサーバーに対しても応用可能なものになっているので、普段活用しているMCPサーバーを使いやすいインターフェースで使えるようにしてみてはいかがでしょうか？

はじめに この記事は KINTOテクノロジーズ Advent Calendar 2025 の 24日目の記事です🎅🎄 こんにちは╭Ꙭ╮⸝o KINTOテクノロジーズ（以下、KTC）で人事グループに所属している、だーしー（ @dashiko ）です。 普段は総務・労務まわりの実務や役員秘書業務、そして各拠点にいるサポートメンバーを束ねるチームのリーダーを担当しています。 私はKTC設立準備の時期から在籍しており、気づけば早 5 年と 10 か月が経とうとしています（古株を通り越して、もはや化石です🐘）。 開発組織の規模も、おかげさまで当時は 30 名ほどだったところから、いまでは 400 名を超える組織へと成長しました。 そんな変化の波の中で、この会社で初めて総務の領域に飛び込み、 気づけばずっと “現場の総務” としてオフィスづくりに向き合ってきました。 この記事では、その総務業務の中でも、全社を横断して動いている総務チーム、 通称「Team総務」の活動にスポットをあててご紹介していきたいと思います📄 ※Team総務 ＝ 兄弟会社KINTOの総務 × KTC側の総務がタッグを組んだ、 全社横断でオフィスや安全・カルチャーづくりを動かしているチームです。 Team総務。戦闘着は三本線のジャージです IT企業と聞くと、まず思い浮かぶのは💡 エンジニア デザイナー PjM・PdM など思い浮かべる人が多いと思います。 その裏側で 「オフィス」という物理インフラ を支えているのが総務です。 とはいえ、社外から見ると、 「IT企業の総務って、実際なにしてるの？」 「“なんでも屋”って聞くけど、実態は？」 というのが正直なところかなと🤔 そこでこの記事では、弊社のTeam総務を例に、 総務がどんな役割を担っているのか この1年、どんなことに走り回っていたのか その中で見えてきた “泥臭さ” と “おもしろさ” あたりを、ご紹介しつつ「IT企業の総務の中身、全部見せちゃいます」 をテーマにまとめていきます 📝 Team総務って何やっているの？ ⚙️オフィス運営：物理世界の SRE みたいな仕事 総務は、ある意味 Office Reliability Engineering です👓 複数拠点（東京・名古屋・大阪・福岡）のオフィス管理 レイアウト変更・増床・移転・リニューアル 通称：民族大移動（＝大規模なゾーニングや配置替え）の設計と実行 椅子・デスク・共用備品などの什器管理 入退館・セキュリティカードの管理 現場レベルだと、 座席表をPowerPointで地道に更新しながら 各部署の関係者とすり合わせをして 移転日・工事日・席替え当日などのマイルストーンを決めて、 自分たちのToDoに落としてひとつずつ潰していく という、「アナログとデジタルのあいだ」くらいの運用で回しています。 見た目は泥臭いけれど、やっていることはほぼプロジェクトワークです💡 🌱働く環境づくり：快適性・利便性・安全性の最適化 「ちょっとした不便」を拾って直すのも、総務の大事な役目です🛠️ 半期に1回、給茶機のフレーバーアンケートを実施してラインナップを調整 空調・照明・騒音に関する相談の一次窓口 季節や状況に応じた設置備品の調整 植栽の配置、感染予防グッズ、サーキュレーターなどの設置など 「1人の“気になる”は、10人の“言わないモヤモヤ”かも」 という前提で、個別の要望とフロア全体のバランスを見ながら、 全体最適の落としどころを探しています🔍 みんなの推しフレーバーを教えて！給茶機アンケート 📘ガバナンスとルール整備：やさしい「社内仕様書」をつくる オフィスを安定運用するには、 「ちょっとしたお作法」から「いざというときの行動」まで、ルールづくりも欠かせません🗒️ 各拠点のオフィスガイド 日常のルール／社内手続きの申請・承認フロー 安全衛生・災害時の行動マニュアル など これらも、できるだけIT企業らしく・読みやすく を意識して整えています。 読まれる前提のルール（見出し・Q&A・図解でサクッと理解できるように） つくって終わりではなく、フィードバックや状況に応じたアップデート ルールで縛るというよりは、 「みんなが迷わず・気持ちよく動けるための社内仕様書をつくる」 という感覚で運用しています📚 社内ルール・ナレッジがぎゅっと詰まった「KINTO Technologies Navi（KTN）」 困ったらまずここを開けばだいたいなんとかなる、を目指して育てています 🎉社内イベント・カルチャーづくり Team総務は、オフィス起点のイベント も実施しています。 七夕🎋 ハロウィン🎃 クリスマス🎄など、オフィスで季節を感じられるイベント企画や装飾づくり 社内掲示板で「総務のつぶやき」を連載し、各拠点オフィスのトピックやイベント報告や総務の舞台裏を発信 こうした取り組みは、単なる「盛り上がりイベント」ではなく、 初めての方も参加しやすい雰囲気づくり 拠点・職種・役職をまたいでのコミュニケーションきっかけづくり オフィスに出社したい！と思ってもらえる仕組みづくり など、カルチャーのOSアップデートの場として設計しています🧩 社内掲示板で連載している「総務のつぶやき」 各拠点の季節イベントやオフィスの小ネタをTeam総務目線でゆるっとお届け 💪ちょっと泥臭いリアル編：総務はわりと物理もやる ここまで読むとスマートに聞こえますが、現場はかなり泥臭いです⚾ だいたい毎月どこかで汗かいてますヽ(´o｀；）ｗ 長尺脚立に乗って備品を修理する 床下電源の配線のために、オフィスの床下に潜り込む オフィス美化のために、定期的にフロアをぐるぐる巡回する 季節装飾やオフィスイベント装飾を、手作りしたり自分たちの手で1枚ずつ貼って回る 座席が固定席運用なので、異動・入退社・兼務を反映した最新の座席表を毎月コツコツ更新する エンジニアがコードをデプロイしている裏側で、 総務は総務で 「オフィスという物理レイヤー」をデプロイ しているようなものです。 総務は決してキラキラした仕事ばかりではありませんが、 泥臭く手を動かしているぶんだけ、 「誰かのための仕事」がくっきり見える職種 だと感じています。 床下掘りの写真を探したら、5年前から床を掘っていました（笑） 2025年の総務活動ハイライト 色々と語ってしまいましたが、ここでざーっと今年1年の総務活動をカレンダー形式で振り返ってみましょう📅 今年1年の総務活動メモリーズ📷 こうして月ごとに並べてみると、 オフィスの移転・開設・リニューアル・ゾーニング調整（全拠点…！） 民族大移動レベルのレイアウト変更（年2回…！） 七夕・ハロウィン・Xmasなど季節イベントの企画・運営 まで、フルコースでやっていた1年だったことに、自分たちでもちょっと笑ってしまいます😆 「オフィスは生き物」とよく言いますが、 その内臓（レイアウト）や血管（動線・配線）、そして“気持ちの温度”をせっせと整えながら、 みんながいつも通り働ける日常を維持していた1年だったなと感じています✨ 来年挑戦したいこと 来年以降、Team総務としてチャレンジしていきたいことを、 「こうなったらいいな」をそのまま宣言しておきます🔥 オフィス改善アイデアを “プロダクトバックログ” 的に管理する 声を集めて、見える場所で優先度をつけて、ちゃんとリリースしていく 手作業前提のオペレーションを「AI前提」に組み替えていく バックオフィスこそAI活用の実験場にして、チェック・転記・集計などの単純作業はどんどんAIに任せていく 「出社したくなる場所」をつくるオフィス企画 ただの“作業場所”ではなく、「行くとちょっと得する」「誰かと話したくなる」オフィスへ強化 季節イベントを「年中行事」レベルまで定着させる 年のリズムとして、「あ、そろそろ七夕だ」「今年のハロウィンは何やるの？」が自然に出てくるくらいまで育てる 利用状況やアンケートなど、データに基づいたオフィス運営を進める 勘と経験だけでなく、「数字を見ながら意思決定できる総務」を目指す おわりに あらためて並べてみると、総務の仕事は オフィス移転・リニューアル・民族大移動 季節イベント・社内イベント 安全・ガバナンス・危機管理 座席調整・オフィス美化　…などなど “見えにくいけれど、なくなると困るもの” ばかりです。 でも、その「見えにくい仕事」を、 こうして少しだけ 透明化してみる のも悪くないなと思っています。 毎年その1年を全力で走り、最終的に行きついたのはこの感覚でした。 すべての仕事には必ず「相手」がいて、 相手を思えば、どんな仕事も愛ある仕事になる。 床下をはいずり回る日も、脚立にのぼる日も、 オフィス内駆け回ってる日も、Slack でひたすらアナウンス文を書いている日も、 その先には誰かの「働きやすさ」があります。 IT企業の総務は、ちょっと泥臭くて、でもわりと愛のある仕事です😌🫶 😲💬 「IT企業の総務って、けっこうプロジェクト型で、ちゃんと“職能”なんだな」 と、この記事を読んで、そんな風に感じてもらえたら嬉しいです。 同じコーポレート領域（総務 / 労務 / 人事）のみなさんとも、 「それ、うちもやってる！」とか 「その視点なかった！」みたいな あるあるや工夫を、いつかどこかで交換できたらいいなと思っています！ “なんでも屋”じゃなくて“オフィスの基盤職”。 IT企業 Team総務の仕事、今年も全力で走りきりました🏃‍♀️💨🎄 最後まで読んでいただき、ありがとうございました╭Ꙭ╮⸝o

この記事は KINTOテクノロジーズ Advent Calendar 2025 の24日目の記事です。 こんにちは！ KINTOテクノロジーズのクリエイティブグループでデザイナーをしている桃井（ @momoitter ）です。 先日、AIを使ったライブペインティング形式で、1時間の制限時間でお題に挑戦する社内イベント 「 Vibe Painting Hour 」 を開催しました。 今回はその第1回として、技術書典に出展する技術書の表紙デザインをテーマに実施しました。 ※技術書典（ぎじゅつしょてん）とは、エンジニアなどの技術者が自身の知見や取り組みをまとめた技術書を持ち寄り、展示・頒布する技術書専門のイベントです。 私はこの「Vibe Painting Hour」で、企画・全体のアートディレクション・イベント設計を担当しました。 この記事では、 なぜこのイベントを企画したのか／どのように設計したのか を中心に紹介します。 なお、「技術書典」についての詳細は、うえはらさんのこちらの記事をご覧ください。 https://blog.kinto-technologies.com/posts/2025-12-12-techbookfest19-report/ 実際にイベント内で表紙デザインがどのように作られていったかは、mayuさんのこちらの記事で詳しく紹介されています。 ※こちらは12/25に公開予定です。 https://blog.kinto-technologies.com/posts/2025-12-29-ai-bookcover-process/ 概要 今回実施したのは、 AIツールを活用したライブペインティング形式のデザインイベント です。 制限時間は1時間 。 5名のデザイナーが同時に画像生成とデザインを行い、最終的に技術書典に出展する技術書の表紙デザインを、その場で決定しました。 完成したアウトプットだけでなく、生成の途中にある思考や試行錯誤のプロセスも含めて共有することを重視しています。 目的 このイベントには、いくつかの目的がありました。 1. AI×デザインの「プロセス」を見せたい 生成AIは、完成物だけを見ると「一瞬で作っている」「魔法のように出てくる」という印象を持たれがちです。 しかし実際には、 プロンプトの試行錯誤 生成結果の取捨選択 どこで割り切るか、どこを粘るかという判断 といった、人の思考が大きく関わっています。 デザイナーが どう考え、どう生成し、どう決めていくのか。 そのプロセスをライブで見せたい（「デザイナーってすごいんだぜ！」を見せたい）、というのが大きな目的でした。 2. キャラクターを「みんなで育てる」フェーズに進みたかった 今回の表紙デザインでは、「るぴあ」というキャラクターを使用しています。 これは私がキャラクターデザインし、これまでAIの検証や、弊社のSNS・イベントでの発信に使われてきたキャラクターです。 これまで、るぴあを使った表現はどうしても自分一人で作ることが多く、表現の幅が狭まりやすい状態でした。 今回はあえて、 他のデザイナーが、るぴあをどう解釈するのか 同じキャラクターでも、どんな表現の違いが生まれるのか を見てみたい、という狙いがありました。 それは、 キャラクターを「個人で作るもの」から「みんなで育てるもの」へ 移行するための、一つのステップでもありました。 企画の経緯 企画のきっかけは、弊社のAI推進メンバーのこの一言でした。 「デザイナーによるAIライブペインティングが見てみたい」 それとちょうど同じタイミングで、技術書典に向けた技術書執筆企画が進行しており「表紙デザインを制作してほしい」という依頼がありました。 そこで、 ライブペインティングのリクエスト 表紙デザインの制作 この2つを 同時に叶えてしまおう と考えたのが、今回のイベントの始まりです。 イベントのネーミングについて イベント名は、以下の3つを掛け合わせて Vibe Painting Hour としています。 AIを使って感覚的にコーディングする「Vibe Coding」から取った「Vibe」 ライブで制作するという意味での「Live Painting」 制限時間1時間を示す「Hour」 事前ヒアリングとお題の作成 イベント前には、依頼主であるうえはらさんにヒアリングを行いました。 技術書の想定読者 技術書全体のトーン 表紙に求める印象や方向性 そこから、下記の方向性が見えてきました。 弊社の認知度からして、「KINTOテクノロジーズだから手に取ってみよう」という動機は生まれづらいので、 キャラクターで引っかかりを作る そのうえで、弊社の 技術力や先進性 を感じさせる 弊社ならではの特色である「 モビリティ 」感も出す ただし本番では、よりライブ感を重視する目的で お題は事前に共有せず当日に発表 されます。 結果として当日は長い説明ができません。 そこで、ヒアリング内容をもとにお題を次の一文に圧縮し、当日デザイナーへ共有しました。 使用ツールとイベント設計の工夫 画像生成 使用するAIツールは指定せず、各デザイナーが慣れているものを選んでいます。 当日は主に以下のツールが使われていました。 Midjourney ChatGPT（画像生成） Photoshop また、今回のイベントでは あらかじめキャラクター「るぴあ」の画像を参加デザイナー全員に配布 しておき、各AIツールで 参照画像（リファレンス）として使える状態 を用意していました。 これにより、 キャラクターの外見や雰囲気が大きくブレない そのうえで、表現の解釈や世界観の違いが自然に出る 「同じキャラクターをどう料理するか」に集中できる という状態を作ることができました。 レイアウト（Figma） 表紙のレイアウト作業には Figma を使用しました。 あらかじめ、 タイトル ロゴ ナンバリング（vol.01 など） を配置した 表紙用のアートボードを、参加人数分用意 しています。 これは、要素の配置までライブでやってしまうと1時間で終わらないためです。 イベント中は、 画像生成に集中できる状態を作る ことを最優先にしました。 なぜこの設計にしたのか ライブペインティングという形式上、 「自由度が高すぎると収拾がつかない」「制限しすぎると面白くない」というバランスがとても重要でした。 キャラクターは固定（参照画像あり） レイアウトは半固定（Figmaで事前準備） 表現と生成のアプローチは自由 という設計にすることで、 1時間という短い時間でも、各デザイナーの個性がしっかり見える状態 を作ることができたと思います。 世界観について 今回のイベントでは、世界観づくりも重視しました。 一回きりのイベントではなく、 今後も続けられるフォーマットにしたい と考えていたためです。 設定はこんな感じです。 ここは、とある町の「クリエイティブ相談所」 デザインに悩んだお客さんが相談に来る そこには腕利きのデザイナーがいる ただし彼らは気まぐれで、1時間以上は働きたがらない 報酬は甘いお菓子 少し遊びのある設定ですが、この世界観があることでイベント全体に一体感が生まれました。 イベントの流れ（60分） イベントは、1時間で「生成 → 判断 → 決定」まで行う構成です。 1. オープニング（約10分） 世界観説明、依頼主紹介、相談内容・お題の発表、デザイナー紹介 2. 生成タイム（前半・約15分） 各デザイナーが画像生成を開始／同時にBGM生成デモや依頼主へのインタビューを実施 3. 中間チェック（約15分） 途中経過を共有し、使用ツールや現在の方向性を紹介 4. 生成タイム（後半・約15分） 中間チェックを踏まえて最終調整 5. 結果発表（約5分） 完成案を並べ、依頼主が採用デザインを選定！ その場で技術書の表紙を決め切るところまで含めて、イベントとして完結させました。 実際にどんな案が出て、どう決まったのか 当日は、同じキャラクターを使い、同じお題を受け取りながら、 驚くほど素敵で個性あふれる表紙案が生まれました。 キャラクターの距離感や視線の向き、世界観の切り取り方、「技術書らしさ」の表現など、 各デザイナーの個性がはっきりと表れています。 最終的には依頼主であるうえはらさんに選定していただき、 デザイナーのmayuさんのデザインが、実際に技術書典で使用する表紙として決定しました！ アンケート結果 イベント後に実施したアンケートでは、 満足度：4.61 / 5 再参加したい：89% という結果でした。 特に多かった声は、 生成プロセスが見られて勉強になった ライブ感があって面白かった 世界観や演出が良かった といったものです。 これらの結果から、アウトプットだけでなく「生成していくプロセス」や「ライブ感」そのものがしっかり価値として受け取られていたことを感じました。 特に「また参加したい」という声が多かったのは、 この形式が一度きりではなく、今後も続けていけそうだという手応えにつながっています。 まとめ AIを使えば、デザインは一瞬でできる。そんなイメージを持たれることもあります。 しかし実際には、 考え、選び、決めるのは人 です。 今回のライブペインティングでは、そのプロセスを1時間に凝縮して見せることができました。 今後も「クリエイティブのお悩みを、AIと一緒に解決する」そんな場を、形を変えながら続けていければと思います。

こんにちは！クリエイティブグループの大金（おおがね）です。 この記事は KINTOテクノロジーズ Advent Calendar 2025 の23日目のものです。 私の普段の業務は、ウェブディレクターとしてサブスクKINTOの中古車の情報設計や、アシスタントマネージャーとしてクリエイティブグループの組織マネジメントを行っています。 今年からは新たに、注力テーマである「ユーザーファースト」の推進担当に手を挙げ、Engineering Officeの守谷（emim）とともにユニットとして活動しています。得意領域で分担している彼女のパートは11日目に紹介されていますので、そちらの記事も覗いてみてください。 https://blog.kinto-technologies.com/posts/2025-12-11-userfirst2025/ 今日は、私が人間中心設計専門家（HCD専門家）の資格を取得した体験の紹介を通して、「ユーザーファースト」という姿勢に対する熱い思いをお伝えしたいと思います。 自社事業で「ユーザーファースト」を掲げながらも、それが組織の壁や既存のプロセスに阻まれ、なかなか本質的な価値に繋がらない… そんな課題を抱える事業責任者や開発担当者の方にこそ、ぜひ読んでいただきたい内容です。5分ほどお付き合いください！ なぜ私が人間中心設計専門家の認定取得を目指したのか？ 「ユーザーファースト」。ウェブで事業展開を行っている事業会社では「聞いたことがない」ということはない重要ワードかとは思いますが、教科書的に「これができていたらユーザーファーストである」といった定義は明確になされていない、あるいはするのが難しいもので、各事業・事業体において望ましい姿はやや異なるかもしれません。 私たちはテックカンパニーとして株式会社KINTOとともにサービス開発、運営を行っていますが、全社に「ユーザーファースト」が行き渡ることを目指すにあたり、その言葉の意味合いや活動のゴール、プロセスを推進担当から見出していく必要がありました。 私が推進担当に手を挙げた理由は、前職で担当していたサービスがユーザーファースト戦略によって大きく躍進した経験があり、あの素晴らしい体験をKTCでも再現したいというものでした。そこには当然、人の巻き込みも必要です。 そこでユーザーファーストの推進担当として、専門領域の知識・実績があることを他者に示し、安心して参画していただく手段として、資格を取得することを思い至りました。この領域の資格としては現在、特定非営利活動法人 人間中心設計推進機構（HCD-net）が認定している人間中心設計スペシャリスト／専門家が適しているということで、受験の準備に入ったのがちょうど去年のこの時期でした。 準備期間 まずは認定を受けたい資格と、その受験資格の確認から入りました。 HCD-netの認定資格は2種類あり、スペシャリストと専門家となっています。いずれもHCDプロジェクトを推進する能力があることを、決められたレポート形式に沿って示すスタイルの認定試験となります。 HCDプロジェクトとは、ユーザーに対する仮説を立て、実際にインタビューやプロトタイピングを経て実証・検証のサイクルを回していくプロジェクトです。私の場合はウェブサービスでの実践経験しかありませんでしたが、特に問題ないようでした。 HCDプロジェクトを推進するスキルセットを持ち合わせ、独力で遂行できる人がスペシャリスト、これにプロジェクト全体や、組織やメンバーへのHCDの導入を含めて推進するリーダーシップやマネジメント力を持ち合わせている人が専門家として認定されます。私の場合は「ユーザーファーストの全社への推進」が目的ですので、専門家を目指すこととしました。 また受験資格も異なり、専門家については「人間中心設計・ユーザビリティ関連の実務経験5年以上を目安／実践事例が3例以上」となっています。パッと思いついて勉強を頑張ればすぐに取得できるものではない、ということがわかりました。過去に携わっていたプロジェクトも含めると要件を満たしているだろうと考え、受験することにしました。 受験対策 HCD-net主催のオンライン説明会に参加し、概要を把握しました。 過去に携わったHCDプロジェクトを概要から詳細に至るまで時系列で書き出し、コアコンピタンスの項目ごとに整理します。コアコンピタンスとは、例えば「利用状況の理解及び明示の能力」を「A1.調査・評価設計能力」などに区分けしたもので、プロジェクトの各プロセスをこの区分けに落とし込むことが求められます。 整理する内容は調査対象、目的、アクション、最終アウトプットでワンセット。これを10項目ｘ３例（審査に必要な必要最低数）、漏れなくダブりなく記載します。 受験中 期間内に指定のドキュメントを提出する形式の認定試験であり、他者からアドバイスを受けることは禁止となっています。正解がわからない中で自力で書き上げる必要があるため、当時の記録や記憶をたどりつつひたすら記載しては読み直し、修正を繰り返しました。 年末年始の休暇のほぼ全てを投入し、指定のドキュメントの確認をはじめてから２週間くらいで提出できました。 合格後、何か変わったか 取得した目的の通り、ユーザーファースト推進のシーンで専門家を名乗ることができています。 これまでの仕事を振り返り、可視化し、他者に伝わるドキュメントに起こすプロセスを経たことで、この分野について一通りは理解・実践しているという自信がついたという側面もあります。 プロジェクトは常に生き物であり、学びが尽きないものなので、まだまだこれから実践を続けて行きたいと考えています。 同時に、ユーザーファーストを自社の文化に昇華すべく、社内外に知識や実践例、Tipsなどを還元していく活動も邁進していきます。 もしあなたが、 「単なるデザイン改善」ではなく、「サービスの本質的な価値と収益性」を追求したい ユーザーの声を、組織と事業戦略を動かす力に変えたい そんなことを感じていたなら、HCDをテーマにしたイベント等にも今後参加しようと考えていますので、どこかでお会いした際には情報交換をさせてください。

この記事は KINTOテクノロジーズ Advent Calendar 2025 の23日目の記事です はじめに：「AIなら一瞬でした！」…で、そのまま提出していませんか？ ※本記事の内容は 2025年12月時点 の情報に基づいています。各サービスの仕様・規約は変更される可能性があるため、最新情報は公式サイトをご確認ください。 「企画書のイメージ画像、AIで作ってみました」「ブログのアイキャッチ、AIなら一瞬でした」 こんなフレーズを、最近あちこちで見かけるようになりました。実際、画像生成AIはビジネスパーソンにとってかなり強力な味方です。 ただ、正直に言うと、「なんとなく便利だから使っているだけ」で終わってしまっているケースも多いのではないでしょうか。 とりあえずAIにお願いして出てきたものを、そのまま資料に貼る なんとなく不安はあるけれど、深く考える時間もない 「みんな使ってるし…まあ大丈夫でしょ」と自分を納得させる 私自身も、最初は完全にこのモードでした。 ですが、仕事で使う以上、「どこにリスクがありそうか」だけでもざっくり知っておくと、仕事の質が一段上がる感覚があります。 本記事では、「なんとなく使っている」状態から、「企業で働く一人として、責任を持って使いこなす」状態へアップデートしていくための実務的なポイントを、できるだけ現場目線で共有していけたらと思っています。 本記事の流れ 「便利さ」の裏にある、3つのモヤモヤを整理する ビジネスパーソンにおすすめの「3つのAIツール」との付き合い方 「組織のルール」より前にできる、個人としての3つの工夫 「便利さ」の裏にある、3つのモヤモヤを整理する まずは、「画像生成AIを使うときに、なんとなくモヤッとしているけど言語化できていない不安」を整理してみます。 画像生成AIのリスクは、大きく分けると次の 3つのカテゴリー に置き換えられます。 法的リスク ：この画像って「誰のもの」なんだっけ？ ブランドリスク ：「AIだから安全」ではない オペレーションリスク ：「なんか不安だけど、聞ける人がいない」 順番に見ていきます。 1. 法的リスク：この画像って「誰のもの」なんだっけ？ AIで画像を作ったとき、ふと頭をよぎる疑問があります。「この画像の著作権って、誰にあるんだろう？」「自分の作品として発表していいのか？」「クライアント案件で使っても大丈夫なのか？」——そんなことを考えたことはないでしょうか。 実際のところ、使用しているツール、どの国・地域の法律が適用されるか、そしてそのツールの利用規約や自社の契約の内容、これらの組み合わせによって解釈はかなり変わってきます。 なので法律の専門家でなくても、少なくとも 「ツールごとに権利の扱いが違うらしい」 「商用利用OKかどうかは、利用規約を一度は見ておいた方がいい」 くらいの感覚を持っておくだけでも、「ちょっと立ち止まるためのブレーキ」がちゃんとかかるようになるかと思います。 そして利用規約を読むのが難しい場合や判断に迷う場合は、独断で使わずに上長、情シス部門、法務担当などに「このツール、業務で使っても大丈夫ですか？」と一度聞いてみるのも一つの手です。 それだけでも、多くのトラブルを防ぎやすくなります。 「無自覚に似てしまう」リスク さらに怖いのが、「無自覚に既存作品に似たものを作ってしまう」リスクです。 画像生成AIは膨大な画像データを学習して動いているので、こちらの意図とは関係なく、 どこかで見たことがある構図 有名キャラクターにちょっと似たもの 某ブランドっぽいロゴ といったものが、それっぽく出てきてしまうことがあります。 そのときに、「AIが勝手に作ったんで…」という言い訳は、残念ながら通用しません。 外に出すのはあくまで「自分（自社）」だからです。 「この画像、本当に大丈夫かな？」と少しでも感じたら、一度立ち止まって、権利面を確認するという習慣をつけておくと安心です。 2. ブランドリスク：「AIだから安全」ではない たとえ法的にはセーフでも、こんなケースはどうでしょうか。社内のトーン＆マナーとまったく合わないビジュアルを使ってしまったり、意図せずステレオタイプな表現が混じっていたり、社会的な配慮を欠く表現になってしまっていたり——。こうしたケースは、法的には問題なくても、ブランド毀損につながりかねません。 生成AIは、学習データの傾向を反映して、思わぬ偏見を含んだ画像を出力してしまうというケースも珍しくありません。 研究レベルでも、職業・性別・人種などに関するステレオタイプを強く反映してしまうことが指摘されています。 「AIで作ったからこそ、人間がチェックする」 という意識がとても大切で、 最後は人間が「目を通す」「悩んだら誰かに見せる」こと を前提にした運用にしておくと安全度が大きく変わります。 3. オペレーションリスク：「なんか不安だけど、聞ける人がいない」 そして地味に効いてくるのが、この「運用まわり」のリスクです。 社内でAIをちゃんと使いこなしている人がまだ少ない どのツールを使っていいか、会社として決まっていない 生成した画像の保管場所がバラバラ 結局、「まあいいか」で自己判断になりがち 例えば、個人の Google アカウントや OpenAI アカウントで業務用の画像を生成していると、退職時にデータが個人側に残ってしまったり、会社側が、どのアカウントで何が作られたか把握できない、といった問題が生じる可能性があります。 可能であれば、法人プランの利用を情シスや上長に相談することをおすすめします。 プロンプトに機密情報を書き込んでしまうリスク もう一つ気にしておきたいのが、 プロンプトに機密情報を書き込んでしまうかもしれない という点です。 たとえ「入力データを学習に利用しない」ことが明示されている法人向けプランを使っていたとしても、入力した情報は一度サービス提供者のサーバーを経由します。 OpenAI や Google、Adobe なども、ヘルプやポリシーで「機密情報は入力しないでください」と明記しています。 例を挙げると、次のような情報は入力を避けるべきです。 例 入力を避けるべき内容 〇〇社向けの提案資料を作る 取引先の企業名・個人名 新製品『△△』のロゴ案を5パターン考える 未発表のプロジェクト名・製品名 売り上げの数値まとめる 社外秘の固有名詞・数値など こうした場面では、固有名詞を伏せて「大手自動車メーカーA社」「金融機関B社」、「来年発売予定の新商品」のように、 抽象化して入力する ことを心がけるとリスクを下げられます。 それでも、AIはちゃんと使えば最強の「相棒」になる ここまでリスク寄りの話が続きましたが、「じゃあ使わない方がいいのか？」というと、そうではありません。 「正しく怖がる」 ことができれば、画像生成AIは本当に頼れる相棒になると感じています。 現場目線でいうと、特にこんなメリットがあります。 イメージの共有が圧倒的に早くなる 「こんな感じの世界観で」と口頭やテキストで説明するより、AIでざっくりイメージを出してしまった方が早い場面はたくさんあります。 「素材探し」からある程度解放される ストックフォトサービスで延々とスクロールする代わりに、「夕暮れの高速道路を走る青いコンパクトカー」など、欲しいシチュエーションを直接プロンプトで指定できるのはメリットが大きいです。 アイデア出しの壁打ち相手になってくれる 「ちょっとやりすぎかも？」くらいの案を遠慮なく試せるので、思わぬ表現に出会えることもあります。 大事なのは、「魔法の箱」として丸投げするのではなく、 自分の意図を持って使う という感覚です。 AIはあくまで「相棒」であって、最終判断は自分がする。その意識があるだけで、活用の質がぐっと変わります。 ビジネスパーソンにおすすめの「3つのAIツール」との付き合い方 ここからは、現場の目線で使いやすい 3 つのツールを、「どういうときに相性がいいか」という観点で整理してみます。 # ツール 特徴 ① ChatGPT 会話ベースでイメージを固める ② Google Gemini Google Workspace連携 ③ Adobe Firefly 権利面の安心感 ① ChatGPT → 「言葉にしながらイメージを固めたい」ときに 会話ベースで「もう少し柔らかい雰囲気に」「右の人物を消して」といった修正ができるのが強みです。 企業での利用について 企業で利用する場合、個人アカウント（Free / Plus / Pro）ではなく、以下の組織向けプランが推奨されます。 ChatGPT Business （※2025年8月に「Team」から名称変更されました） ChatGPT Enterprise これらのプランでは、デフォルトで入力データが学習に使われない設定になっていると説明されています。 一方で、 Free / Plus / Pro といった個人向けプランでは、デフォルトで会話内容がモデル改善に利用される設定だと説明されています。 設定画面でオプトアウトしない限り学習に利用される可能性があるため、業務利用時は特に注意が必要です。 相性が良いシーンの例 企画の初期段階で、コンセプトの方向性を探りたいとき 「こんな感じ？」と壁打ちしながら、画像のバリエーションを試したいとき テキストと画像をセットで考えたい（タイトル案＋キービジュアル案 など）とき 公式サイト（ビジネスデータのプライバシー、セキュリティ、コンプライアンス） ② Google Gemini → 「Google Workspace との連携」を重視したいときに 「スライド用の背景画像をサッと欲しい」「提案資料の中に入れるイメージをその場で作りたい」といったニーズにフィットします。 企業での利用について Google Workspace の商用プランでは、入力データや生成物はAIの学習に利用されません（商用データ保護が適用されます）。 一方で、 個人アカウント から Gemini アプリを使う場合は、会話内容が製品改善やモデル改善に利用されることがあります。 業務で使うなら、自分がどの契約・どのアカウントで Gemini を使っているかを必ず確認しておきたいところです。 相性が良いシーンの例 提案資料に差し込む、リアル寄りのイメージ画像が欲しいとき すでに Google Workspace を業務で使っているチーム ドキュメントやスライドの中で、そのままプロンプトを書いて画像を生成したいとき 公式サイト（Google Workspace の生成 AI に関するプライバシー ハブ） ③ Adobe Firefly（アドビ ファイアフライ） →「権利関係のクリーンさ」を最優先したいときに Photoshop や Illustrator でおなじみの Adobe が提供する画像生成AIです。 最大の特徴 は、Adobe が Firefly について、Adobe Stock などのライセンス済みコンテンツや著作権が消滅したパブリックドメイン画像など、 権利的にコントロールされた素材を中心に学習している と公式に明示している点です。 もちろん、これだけで「何があっても絶対安心」とは言えませんが、コンプライアンスを重視する企業のWebサイト、広告クリエイティブ、大規模なキャンペーンビジュアルなどを作るときに、ひとつの"安心材料"として選びやすいツールです。 IP補償について また、エンタープライズ向けの Firefly ソリューションやAdobe Stock の一部の生成機能では、一定の条件を満たした場合に、 生成物に対するIP補償 が提供される仕組みがあります（対象となるプランや条件は契約形態によって異なります）。 「会社でAdobeに入っているから大丈夫」と思い込まず、「 自社の契約はIP補償の対象プランか？ 」を一度確認することをおすすめします。 相性が良いシーンの例 既に Photoshop / Illustrator を使っていて、その延長で生成AIを使いたいとき 権利面・ブランド面への配慮が特に重要なプロジェクト 生成画像に Content Credentials（生成経路の情報）を付けて管理したいとき 公式サイト（包括的で安全に商用利用できるAIを活用したビジネス用コンテンツ制作） 公式サイト（Adobe Fireflyによる生成AIへのアプローチ） 「組織のルール」より前にできる、個人としての3つの工夫 「うちの会社、まだAIのルールとか全然決まってないんだよね…」という方も多いと思います。 まずは、社内にすでにルールやガイドラインがないかを確認してみてください。 すでにある場合は、当然そちらが最優先です。 「確認したけど特にない」「これから整備される予定」という状況であれば、今日からできる小さな工夫を3つだけ挙げておきます。 工夫1：使うツールの「利用規約をまず確認してみる」 細かいところまで読み込めなくても、少なくとも、次のようなポイントは一度チェックしておくと、いざという時に助かります。 ^1 確認すべきポイント 商用利用はOKか 再配布・譲渡はどこまで許されているか クレジット表記が必要かどうか 「AI生成です」と書く必要があるのか この画像は「自分のもの」として扱っていいか ^2 権利がユーザーに帰属するのか それとも、サービス側からライセンスを付与される形なのか ツールによって、 「入力と出力はユーザーに帰属します」 「ユーザーに一定のライセンスを付与します」 といった表現が分かれますし、OpenAI や Adobe のように、ビジネス向けサービスでIP補償を用意しているケースもあります。 ポイント 「なんとなく大丈夫そう」ではなく、最低限、上の項目について 「どこに何が書いてあるか」だけでも見つけておく と、自分では気づかないリスクがグッと減ります。 工夫2：「これはアウトかも？」と思ったら、一度人に見せる 有名キャラに似ていないか ブランドロゴっぽい要素が入っていないか 社会的な配慮を欠く表現になっていないか など、自分だけの判断では不安なときは、チームメンバー、デザイナー、上長などに「どう思う？」と一度聞いてみることが必要だと思います。自分では気づきにくいグレーゾーンを別の人があっさり見抜いてくれる、ということもよくあります。 工夫3：プロンプトと生成物を「メモしておく」 「この画像どうやって作ったんだっけ？」という振り返りのためだけでなく、万が一、第三者から「この画像、似ていませんか？」と問い合わせが来たときに、「このツールで、このプロンプトで生成しました」と説明できる状態にしておくことが、自分や会社を守ることにつながります。 完璧な管理まではしなくても、以下の内容を記録しておくと説明しやすくなります。 記録レベル 内容 最低限 どのツールを使ったか（ChatGPT、Gemini、Firefly など）、いつ生成したか（日付） 推奨 プロンプトの全文、生成した画像のファイル名と保存場所、使用目的（社内資料 / クライアント提案 / Webサイト など） スマホのメモアプリや、生成した画像と同じフォルダにテキストファイルを置いておくだけでも、何もしないよりはるかに役立ちます。 EU AI Act や G7広島プロセス など、生成AIの透明性や説明責任が重視されつつあります。 「どのツールで、どんな指示を出して、どの画像を使ったか」をざっくりでも追えるようにしておくことは、こうした流れに備える意味でも有効です。 おわりに：「なんとなく」から「意識して使う」へ 画像生成AIは、使いこなせば本当に頼れる相棒になります。 でも、「便利だから」とただ流されるのではなく、リスクを意識しながら使うことで、仕事の質も、周囲からの信頼も、一段上がるはずです。 完璧なルールが整うのを待つ必要はありません。 利用規約を見る 迷ったら誰かに聞く 使ったツールやプロンプトを軽く記録しておく こうした小さな実践の積み重ねが、 「なんとなく使っている人」と「 責任を持って使いこなしている人 」の差になっていくのだと思います。 免責事項 本記事は、画像生成AIに関する一般的な情報の共有を目的としたものであり、 法律的な助言を行うものではありません。 具体的な判断が必要なケースでは、 各サービスの最新の利用規約や FAQ 所属組織のルール・ガイドライン 必要に応じて専門家（法務・弁護士等） に相談することをおすすめします。 ただし、ここが少しややこしいところです。 「権利はユーザーに帰属」と書かれているサービスもあれば、「ユーザーにライセンスを付与」といった書き方のサービスもあります。 特にクライアントとの契約で「著作権の譲渡」が条件になっている場合は、自己判断せず、利用規約の該当部分を法務や上長に見せて「この条件で問題ないか」を確認することをおすすめします。

この記事は KINTOテクノロジーズアドベントカレンダー2025 の22日目の記事です🎅🎄 はじめに こんにちは。KINTOテクノロジーズ株式会社（略して、KTC）で iOS, Androidモバイルアプリを開発している、方茂碩（バン・ムゥソク、Bahng Mooseok）です。 これまで「Global KINTO App」、「KINTO かんたん申し込みアプリ」などを担当し、現在は 「KINTO Unlimited」の開発を行っています。 「KINTO かんたん申し込みアプリ」は、新車のサブスクサービスであるKINTOの見積りから審査までができるアプリで、「KINTO Unlimited」は、契約内容の確認、ドライブサポートやクルマのアップグレードの申し込みなどができるアプリです。 今回は、WWDC25に参加してきましたので、テックブログにまとめてみました。 私は2008年からiOSアプリ開発に携わっており、当時はまだ「iOS」ではなく「iPhone OS」と呼ばれていた時代です。 長年にわたって、WWDCは技術情報の収集や最新技術のキャッチアップにおいて最も重要なイベントだと感じてきました。にもかかわらず、今回が初の現地参加となり、とても感慨深い体験となりました。 やはり現地ならではの没入感は、オンライン参加とはまったく違いました。 Check-in and welcome reception @Apple Infinite Loop 日曜日の午後、Appleの旧社屋「Apple Infinite Loop」にて、事前チェックインとウェルカムレセプションが行われました。 WWDCのバッジとグッズを受け取り、そのまま夕方までウェルカムパーティが開催されました。 WWDC25の参加バッジ、KTCからはほとんどのアプリを TOYOTA FINANCIAL SERVICE CORPORATIONの名前でリリースされています WWDCも、この場所も憧れだったので、結構並びますが、WWDC25のモニュメント前での記念撮影は必須です！行列にはなりますが、並ぶ価値ありです。 前日夜には日本からの参加者が集まる交流会にも参加していたため、その時に出会った方々と話したり、会場内にいるAppleの社員と話したりと、楽しい時間を過ごせました。Appleの偉い方から「あそこが Steve Jobsのオフィスでしたよ」と直接説明を聞けたのは、貴重な経験でした。 そして、Apple Japanの方ともお話する機会があり、日本に戻ってからのアプリ改善に向けた取り組みについて相談することができました。 Main Event @Apple Park - Keynote, Platforms State of the Union WWDC期間中、自分を苦しめたのが時差ボケです。メインイベントの日もちょっと寝坊してしまい、Keynoteの時間にギリギリ到着。 屋根のある良い席も確保できず、Caffe Macsでの朝食も慌ただしくなってしまいました。メインイベントの日は早めに行動するのをおすすめします。 遠い＆日差しが強い！ いよいよKeynoteが始まります。 Keynoteの冒頭では、Apple制作の映画F1の予告編がサプライズで上映されました。ちなみに、まだ映画館で公開前でしたが、WWDCの三日目の火曜日の夜、Steve Jobs Theaterで特別上映されました。もちろん席に限りがあるので、申し込みが必要。私はメール確認が遅れ、申し込みに間に合いませんでした。突発的なイベントにも対応できるよう、WWDC期間中は常にメールをチェックすることを強くおすすめします。 Keynoteが終わると、ランチです！ Cupertinoの夏は日差しが非常に強いですが、Apple Parkの内庭でのランチは最高です。 前夜から全て無料で提供される食事、デザートもWWDC現地参加の楽しみの一つです！ 午後は「Platforms State of the Union」が開催。開発者向けにより技術的な内容が発表されます。 今回のKeynoteと Platforms State of the Unionの目玉は、Liquid Glass UIと Apple Intelligenceでした。 Liquid Glassは、他の参加者からも好評で、私も非常に洗練された印象を受けました。 Apple Intelligenceでは、新しいFoundation Models Frameworkが登場。Appleアプリ開発において今後、非常に重要な基盤技術になると感じました。 In-person Labs WWDC中でも特に貴重なのが「In-person Labs」です。Appleのエンジニアやデザイナーに直接質問できる機会です。 想像以上に多くの方が対応をしていて、あまり待たずに相談することができました。 ただし一つ反省点が。この時間は概念的、抽象的な質問よりは具体的なケースに基づく質問の方が向いていると思いました。Conciergeの方が質問内容に応じて専門スタッフに繋いでくれるのですが、内容が曖昧だと割り振りにも困っているように見えました。 でも、WWDC期間中、Appleの社員と話せる機会は In-person Labsだけではありません。 ウェルカムパーティや、三日目の Developer Activitiesなど、機会は十分にあるので、聞きたいことをたくさん準備すると、より濃い体験になると思います。 Developer Activities @Apple Developer Center Cupertino 公式イベントの三日目、火曜日です。 Apple Developer Centerで Developers Activitiesが開催されました。 このイベントは事前申請が必要で、WWDCの一週間前ぐらいに案内メールが届きますが、ちょっと遅くなると参加できなくなるか、当日会場の前で空きを待つしかないので、メールが届いたら、即申し込み推奨です。 今回のテーマはLiquid Glass UI。 登壇したAppleのデザイナーやエンジニアたちが、UIの哲学や開発エピソード、さらにはライブコーディングまで披露してくれました。 このセッションはオンライン配信もされない、現地限定コンテンツなので、非常に価値の高い体験でした。 非公式カンファレンス、イベント - One More Thing Conference, Core Coffee WWDC開催中は、Cupertino周辺で多くの非公式Apple系イベントも開催されています。 twostrawsで知られるPaul HudsonさんがWWDCごとにまとめてくれているイベントリストがあるので、要チェックです！ https://github.com/twostraws/wwdc 今回はその中から、「One More Thing Conference」と 「Core Coffee」に参加しました。 「One More Thing Conference」では、公式発表された新技術をその場で実装・検証しながら、実用的な知見を深められるのが印象的でした。 非公式ながら、世界中の開発者と深く交流できる機会となりました。 まとめ 毎年WWDCの内容を追いかけてきた私にとって、今回、初めて現地で参加できたことは、とても意義深い経験となりました。 特にApple純正のFrameworkの理解は、品質・メンテナンス性の高いアプリを作るうえで欠かせないものです。 現地参加を通じて、その重要性をあらためて実感し、新たな刺激とモチベーションを得ることができました。

こんにちは、 @ahomu です。この記事は KINTOテクノロジーズ Advent Calendar 2025 の22日目の記事です🎅🎄 2025年2月に KINTOテクノロジーズの開発組織を強くしたい Engineering Office のご紹介 という記事でご紹介した弊チームについて、発足から1年弱経過した現状とメンバー紹介を書きます。 1年を振り返って 今年の中頃にFindyさんの開発生産性カンファレンスでも弊チームについて登壇させてもらいました。 https://findy-tools.io/articles/kinto-technologies-dev-productivity-con-2025/133 我々は「トヨタグループの内製開発部隊たるKINTOテクノロジーズ（KTC）の開発力・組織力を高めるためにケイパビリティやカルチャーを獲得/変化するための働きかけ」という、抽象的なミッションを担っています。 学びと理解と関係づくり 登壇時にも言及したことですが、我々のような社歴の浅いメンバー/チームが横軸活動を進める上で大事なことは、独りよがりにならず、これまでとこれからをセットで示すことです。 これまでのトレードオフを知ることで、現状の意味・意義を知る 問題や不足を見つけるのではなく、今できていることを知った上で伸び代を見つける EOは各人の領域でこの動きをしっかり行うことができたと思います。また、実際に頼りにしてもらえる機会も増えてきており、まだ小さいながらも着実に変化を起こせています。 全社のカバレッジとしては不足もありつつですが社内各所、各レイヤーとも様々な関係を築けました。 個人商店と多様性のシナジー 活動が本格化するにつれて専門性の異なる個人商店的なチームであることの明確な強みが出てきたように感じています。専門領域以外にも出身業界や属性に多様性があるチームなので、ひとりひとりが様々な視点をもって全社に向けてアプローチをしています。 その過程であつまった情報や知見を持ち寄ると、同じ対象にも色々な物の見方や、立場による見解の差異がよく見えてきます。所感と事実を正しく扱うことで、KTCの次の可能性や、より具体的な打ち手を考える中で大きな助けになっています。 また、ひとりひとりが社内営業であると同時に、組合として助け合うことで「この仕事はこのひとのほうが得意だからパスしちゃお」がうまくワークすることも増えています。個人的な経験だと同質性による強行突破を図るような仕事が多かったので、今のこのチームで多様性のメリットが強く感じられることに面白みを感じています。 実際の取り組みとゆかいななかまたちを紹介するぜ 今年のAdvent Calendarの中で各自が取り組みを紹介しているので、ここでは記事リンクとあわせてメンバー紹介をしていきます。（ドコドコドコ……🥁 🚀 「一人二役、開発プロセス改善の北風と太陽」Y.Naitoさん https://blog.kinto-technologies.com/posts/2025-12-17-releasefirst/ SPI (Software Process Improvement) スペシャリストとしてEO発足以前から社内各所で活動しています 記事にある「リリースファースト」はまさにNaitoさんの真骨頂。スクラムの雰囲気に乗っかってきただけの自分としては、開発プロセスという一連の営みに対する解像度の高さを学ばせていただいております 北風と太陽、モードを使い分けてるけど、なんにせよパワフルさに社内で定評がある。 亀十のどら焼きを布教するプロ 🎨 「EOの特異点、KTCのデザインをデザイン中」emimさん https://blog.kinto-technologies.com/posts/2025-12-11-userfirst2025/ チーム名称的にエンジニアが増えるかと思いきや、emimさんはデザイナーです。デザインエンジニアとかでもなく純粋にプロダクトデザインが直近の専門 記事では、形骸化しがちな「ユーザーファースト」を再定義する挑戦が綴られています。開発の中でデザインとエンジニアリングのブリッジをしてきた経験を活かし、EOとして内製開発組織の変革に挑戦してくれています 「社内フリーランスで動き回る前提で、しくじると社内無職まっしぐらですよ！（乱暴な意訳）」という珍妙な求人訴求に興味を示してくれた奇特な方。 おいしいコーヒーだいすき 🍔 「バーキン担当アクセシビリティ番長（仮）」辻さん https://blog.kinto-technologies.com/posts/2025-12-09-What-I-want-to-achieve-as-blind-person-at-mobile-company/ 入社したてホヤホヤ。アクセシビリティエンジニアとして幅広く社内外でご活躍予定 一連の活動を通してアクセシビリティ〜ユーザビリティが直接的に高まる → グループ会社としての使命を本質的に果たせるようになることはもちろん、多様な利用環境に関する気付きを得られるので広くユーザーに対して深い洞察を得られる組織の育成につながると考えています（筆者観点） 東京のオフィス近くにあるバーガーキングで ワッパーを食べる約束？をしている 👔 「Engineering Office は心の主務」ahomu じつは7月から人事マネージャーを兼任している。プロ人事の皆さんに支えられています EOではアウトプットや進め方のレビューだけしてるマネージャー業 EOが仕掛けている組織の変化に備え、私は人事としてチェンジマネジメントに携わっている、というのが正しいフォーメーション説明 さいごに KTCのEngineering Officeのご紹介でした。年明けにはSET（Software Engineer in Test）としての専門性を持つメンバーもジョイン予定です。 まさか1年でこんな人が増えるとは思っておらずびっくりですが、求人要件がファジーすぎて難しいので、引き続きリファラル中心で積極的な採用はしていません。 👉 KINTOテクノロジーズ 採用情報（オープンポジション）はこちら Engineering Office決め打ちでなくても大丈夫なので、ご興味がある方は何らかの手段でコンタクトとっていただければ色々お話させていただきますので、よろしくお願い致します。

この記事は KINTOテクノロジーズアドベントカレンダー2025 の22日目の記事です🎅🎄 はじめに こんにちは、KINTOテクノロジーズ Mobile Assistanceマネージャー&KMPチームリードのYena Hwangです。 本記事は「Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ」シリーズの最終回Part 3です。Part 1ではハイブリッド開発を選んだ背景を、Part 2では具体的な実装方法を紹介しました。今回はSwiftUI連携の詳細、CMP vs Flutter比較、そして実践で直面した落とし穴と導入戦略を解説します。 本シリーズの構成 Part 1：なぜハイブリッドなのか Part 2：実装ガイド Part 3：SwiftUI連携と技術Tips ← 現在の記事 SwiftUIとCMPの相互埋め込み ハイブリッドアーキテクチャの核心は、SwiftUIとCompose Multiplatform（CMP）を自由に組み合わせられることです。ここでは、共通モジュールを実際にネイティブ画面に、どう統合するのかをご紹介します。 ComposeをSwiftUIに埋め込む SwiftUIにComposeを埋め込む方法です。 まず、CMP側では UIViewController を返します。 // AppComposeUI.kt fun createProfileVC( user: User ): UIViewController { return ComposeUIViewController { ... } } そしてSwiftUI側では UIViewControllerRepresentable を使って、そのコントローラをラップします。 // ComposeViewContainer.swift import SwiftUI import shared // Import the shared KMP framework struct ComposeViewContainer: UIViewControllerRepresentable { let user: User func makeUIViewController(context: Context) -> UIViewController { // Use the Compose wrapper to create the UIViewController return AppComposeUIKt.createProfileVC(user) } func updateUIViewController(_ uiViewController: UIViewController, context: Context) { } } これでSwiftUIの中にCMPの画面が自然に表示されます。 以下は ComposeViewContainer に user を渡している例です。 // ContentView.swift struct ContentView: View { let user: User var body: some View { VStack { Text("SwiftUI Header").font(.headline).padding() // Embed the Compose UI inside SwiftUI. ComposeViewContainer(user: user) .frame(height: 250) List { Text("SwiftUI Item 1") Text("SwiftUI Item 2") } } } } このように書くだけで、 CMPの画面をそのままSwiftUIのコンポーネントとして扱える ようになります。 SwiftUIをComposeに埋め込む 今回は、逆に、 SwiftUIをComposeに埋め込む方法 です。 まずKotlin（iosMain）側にエントリーポイントを用意します。SwiftUIをComposeに埋め込むための入口です。KotlinはSwiftUIを生成しません。Swiftから () -> UIViewController のファクトリを受け取ります。 // ComposeEntryPointWithUIViewController.kt fun ComposeEntryPointWithUIViewController( createUIViewController: () -> UIViewController ): UIViewController = ComposeUIViewController { Column( Modifier .fillMaxSize() .windowInsetsPadding(WindowInsets.systemBars), horizontalAlignment = Alignment.CenterHorizontally ) { Text("Embedding SwiftUI into Compose") UIKitViewController( factory = createUIViewController, modifier = Modifier.size(250.dp).border(2.dp, Color.Blue), ) } } そしてCompose側では UIKitViewController() を使って、SwiftUIビューを表示します。 次にSwift側の実装です。ここでは MySwiftUIView を定義して、 UIHostingController でラップします。 // MySwiftUIView.swift struct MySwiftUIView: View { let userName: String var body: some View { VStack(spacing: 8) { Text("Native SwiftUI Content").font(.headline) Text("Welcome, \(userName)") } } } // Pass SwiftUI to Kotlin entry point struct ComposeViewControllerRepresentable: UIViewControllerRepresentable { func makeUIViewController(context: Context) -> UIViewController { // Pass a factory to Kotlin that returns a UIViewController. // Here we wrap our SwiftUI view in a UIHostingController. return Main_iosKt.ComposeEntryPointWithUIViewController(createUIViewController: { UIHostingController(rootView: MySwiftUIView(userName: "Yena Hwang")) }) } func updateUIViewController(_ uiViewController: UIViewController, context: Context) {} } そして、そのコントローラを ComposeEntryPointWithUIViewController にファクトリとして渡します。このようにして、結果的に SwiftUIの画面をComposeの中に表示する ことができます。 ネイティブUIコンポーネントの埋め込み：MapView 次に、ネイティブUIコンポーネントを利用した例です。CMP側にネイティブUIコンポーネントを埋め込んだアプリの動作をご覧ください。このMapViewはiOSの ネイティブコンポーネント です。 // MapContainer.kt // commonMain @Composable expect fun MapContainer( modifier: Modifier = Modifier, dealers: List<Dealer> ) // iosMain @Composable actual fun MapContainer( modifier: Modifier, dealers: List<Dealer> ) { UIKitView( factory = { // platform.MapKit MKMapView(frame = CGRectZero.readValue()).apply { showsUserLocation = true delegate = MapDelegate( ... ) } } ) } 共通コードでは expect 関数を宣言し、iOS側では actual を実装しています。そして UIKitView を使って、 MKMapView をそのまま埋め込んでいます。 このように、 expect/actual パターンを使うことで、共通インターフェースを維持しながらプラットフォーム固有のネイティブコンポーネントを自由に埋め込むことができます。 CMP vs Flutter：なぜCMPを選んだのか ここまでCMPとネイティブUIの使い分けについて見てきましたが、実は他のクロスプラットフォームのフレームワークでも同じような課題があります。 ネイティブビュー統合方式の決定的な違い 例えばFlutterの公式ドキュメントには、『Platform Viewにはパフォーマンス面でトレードオフがある』と明記されています。 区分 CMP Flutter レンダリング Inline Rendering 😄 Overlay 🥲 特徴 高速で効率的 重いビューでカクつき 技術的な違い CMPとFlutterでは、ネイティブUIと埋め込みUIの相互運用方式が異なり、パフォーマンスに大きな差が出ます。 Host UI → Embedded UI Rendering path Performance impact Native → CMP Android: AndroidView inside Compose (same View system) iOS: CMP Skia surface hosts a UIKit view via UIKitView Very Low (Android) / Low–Moderate (iOS) CMP → Native Android: ComposeView in a ViewGroup (Compose runs on platform renderer) iOS: SwiftUI/UIViewController hosts ComposeUIViewController (Skia surface inside) Low (Android) / Moderate (iOS) Native → Flutter Flutter renders via Skia/Impeller; native view injected as PlatformView (texture/layer composition) Moderate; visible stutter on heavy views (Map, WebView) Flutter → Native Native Activity/VC hosts Flutter engine surface Extra startup cost (engine warm-up), stable after warm-up CMPの強み ネイティブMapViewをそのまま使用し、ネイティブAPIでアイコン/経路レンダリング MKMapViewなどのネイティブコンポーネントを直接配置 コンポーネント単位で交換可能 ネイティブパフォーマンスとアクセシビリティ維持 複雑なハイブリッドUIパフォーマンス比較 Framework Startup Time Memory Usage UI Smoothness Native ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ CMP + Native ⭐⭐⭐ ⭐⭐ ⭐⭐⭐ Flutter + Native ⭐⭐ ⭐⭐ ⭐⭐ 実践で直面した落とし穴 "Every solution breeds new problems." — Arthur Bloch ここまでCMPとネイティブUIの組み合わせの利点を見てきましたが、どんな技術にも課題はあります。私たちがKMP/CMP開発で実際に直面した落とし穴を紹介します。 KMPロジックレイヤー 1. HTTP/TLS/リダイレクト/クッキー 症状：プラットフォーム別エンジンが異なり、クッキー永続性、リダイレクト、TLSピニングが異なる動作 解決：タイムアウト/キャッシュ/ロギング共有設定 + DIやexpect/actualでプラットフォーム別エンジン+セキュリティポリシー注入 2. 正規表現の違い 症状：JVMはjava.util.regex、iOS/Nativeは ICUベースエンジン使用。 \R 、可変幅lookbehindなどがiOSで異なる動作またはサポートなし 解決：複雑な機能を避ける、シンプルなサブパターンに分離、エンジン交換可能なアダプター構成 3. タイムゾーン & DST 症状：プラットフォーム別タイムゾーンDBとフォーマッティング規則が異なる 解決：すべての計算はkotlinx-datetimeで、フォーマッティングはexpect/actualでプラットフォームに委任 CMP UIレイヤー 1. フォント & タイポグラフィ（CJK/絵文字） 症状：プラットフォーム別フォールバックが異なり、行の高さ、省略、絵文字幅が異なる 解決：フォントバンドル、フォントファミリー/ウェイト明示的宣言、lineHeight/letterSpacing明示的設定 2. 省略/テキスト測定の違い 症状：iOS/SkikoテキストレイアウトがAndroidとピクセル単位で一致しない 解決：maxLines + TextOverflow.Ellipsis使用、「ぴったり」な仮定を避ける、主要画面スクリーンショットリグレッションテスト 3. スクロール & ジェスチャー物理 症状：iOSの慣性がより「滑らか」で、ネストスクロールの感触が異なる。また、CMPのScrollの中にネイティブのScrollを入れると、内側のScrollが動作しない問題もある 注意：スクロール物理設定を抽象化してプラットフォーム別分岐、複雑なネストスクロールページは単純化。Scroll ViewのUXは設計段階から調整が必要 導入戦略：プロダクト段階別アプローチ CMP/KMPの真の強みは 柔軟性 です。共有コードとネイティブコードの比率を自由に調整できるため、プロトタイプでは再利用を最大化し、プロダクトが成熟したらネイティブ比率を高めることができます。 新規プロダクト：共有比率を高くスタート 段階 共有比率 目標 リソース状況 Start Stage ~99% 迅速なリリース、アイデア検証 限られた開発リソース Growth Stage ~80% プロダクト拡張 + ネイティブUX強化 標準開発リソース Maturity Stage ~50% パフォーマンス最適化、長期保守性、チーム専門化 豊富な開発リソース 既存プロダクト：段階的導入 1. Start Small（1%） 最も安全なエントリーポイント。最も小さくリスクの低い領域にKMP/CMP導入 2. Stepwise Expansion（20%） 安定性と確信を確保しながら導入範囲を拡張 3. End Stage（~50%） 共有コードとネイティブコードの持続可能なバランスポイントに到達 おわりに ハイブリッドアーキテクチャを導入して得られた成果をまとめると： 項目 Before（従来・ネイティブ） After（ハイブリッド） 開発効率 両OS別々に実装 50%削減、一箇所でバグ修正 コスト 重複作業・すり合わせ必要 コミュニケーション・QA・保守削減 チーム OS別に専門エンジニア必要 少人数で両プラットフォーム対応 品質 ネイティブ品質 ネイティブ品質を維持しながら共有 柔軟性 ネイティブのみ 必要な部分だけ共有可能 ネイティブの強みを活かしながらコードを共有できる ——これがハイブリッド戦略の最大のメリットでした。 DroidKaigiで発表しながら、多くの方々が同じ悩みを持っていることを感じました。これからKMP・CMPの導入を検討しながら、両OSのネイティブコードも活かしたハイブリッドアーキテクチャを準備している方々に、私たちのチームの経験が少しでも参考になれば幸いです。 重複作業を減らし、両OSに効率よく対応しながら、高品質なアプリを素早くユーザーに届ける——KMP・CMPを活用したハイブリッド開発を、ぜひ検討してみてください。 こちらは「Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ」シリーズのPart 3（最終回）です。

この記事は KINTOテクノロジーズアドベントカレンダー2025 の21日目の記事です🎅🎄 KINTOテクノロジーズで my route for iOS を開発しているRyommです。 最近、my routeアプリ内にTipKitを導入しました。その際TipKitで外部から表示状態をコントロールする方法が少し癖があったので、紹介します。 実際のTipKit使用箇所 背景 TipKitとは、iOS17以降で使えるようになった、アプリの機能を見つけるのに役立つヒントを出すためのフレームワークです。 https://developer.apple.com/documentation/tipkit/ TipKitを使うと、手軽に吹き出しのポップアップなどを出せたり、TipKit内で表示状態のコントロールを行えたりします。 しかし、TipKit内で全てが完結するということは、Viewとロジックが密接に絡み合ってしまうということでもあります。これでは既存のアーキテクチャと齟齬が生じてしまいます。 また、my routeでは以前からTipKitを使わずに似たような表示コントロールを行なっていたため、既存のロジックをTipKitに持ってこようとすると一度全てのユーザーの表示状況がリセットされてしまう問題もありました。 そこで、UserDefaultなどに保存してある既存の状態を維持したまま、どうにかTipKitに外部から表示状態を差し込みたいと考えました。 TipKitの基本の使い方 TipKitは基本的に、以下のように書いて使います。TipViewStyleを使ってスタイルをカスタマイズすることもできます。 import TipKit struct FavoriteLandmarkTip: Tip { // 表示文言 var title: Text { Text("Save as a Favorite") } // 表示状態の条件を制御するマクロ @Parameter static var userIsLoggedIn: Bool = false var rules: [Rule] { #Rule(Self.$userIsLoggedIn) { // ログイン状態ならTipを表示 $0 == true } } } TipKit内にユーザーアクションを定義して追跡することもできます。 struct FavoriteLandmarkTip: Tip { // 追跡するユーザーアクションを一意のIDを持つイベントとして定義 static let didViewLandmark: Event = Event(id: "didViewLandmark") var rules: [Rule] { #Rule(Self.didViewLandmark) { // イベントが3回以上発生したらTipを表示 $0.donations.count > 3 } } } このように、TipKit側で独自に表示状態の条件を管理しています。 しかしこのままでは上述の通りに問題があります。 TipKitに外部から表示状態を差し込めるようにする @Parameter マクロを利用して、表示状態を差し込めるようにします。 @Parameterでラップされた値が変更されると、依存するTipルールが再評価されます。 そこで、外部の値を @Parameter を経由して変更してあげることで、TipKitの状態をコントロールすることができます。 https://developer.apple.com/documentation/tipkit/tips/parameter まず、TipKit自体は以下のように定義します。ここでは呼び出し側のViewに定義してある @Parameter をみてTipの表示有無を判断しています。 import TipKit struct MemoTip: Tip { var title: Text { Text("気に入った記事のURLはこちらからおでかけメモに追加ができます") } var rules: [Rule] { #Rule(ParentView.$isPresentingMemoTip) { $0 == true } } } 外部から値を受け取るためのパラメータとは別に、TipKit用に @Paramter にラップしたパラメータを用意します。 onAppear と onChange によって2つのパラメータが同期するようにしています。 struct ParentView: View { @Binding var showTip: Bool // 外部から値を受け取るパラメータ。本当はもっと構造体になってたりObservedObjectだったりする。 @Parameter static var isPresentingMemoTip: Bool = false // TipKit用に外部の値をラップするパラメータ var memoTip = MemoTip() var body: some View { SomeView() .safeAreaInset(edge: .bottom) { memoButton .popoverTip(memoTip, arrowEdge: .bottom) // チップを出す場所 .onAppear { // Viewがつくられた最初はonChangeが動かないので、初期値を挿入 ParentView.isPresentingMemoTip = showTip } .onChange(of: showTip) { _, newValue in // 外部から変更があったら、@Parameterマクロに値を挿入 ParentView.isPresentingMemoTip = newValue } } } } こうすることで、ロジックをViewから切り離せるようになりました。 ViewModelなどで表示状態の条件のロジックを書いて、その状態をshowTipに渡してあげればTipKit側の状態も更新されます。いい感じです。 まとめ TipKitの表示状態を外部からコントロールできるようにする方法を紹介しました。 TipKitはiOS17から利用できるので、これから利用するケースも徐々に増えていくと思います。 完全に新規の機能として作成するのであればTipKitで完結させる方が良いとは思いますが、既存のものを移行する場合は困るシーンもあるので、この記事が役立つと良いなと思います。 それでは、メリークリスマス🎄

この記事は KINTOテクノロジーズ Advent Calendar 2025 と 技術広報 Advent Calendar 2025 の21日目の記事です🎅🎄 何の記事？ 本記事は、私が技術広報として働く中で「発信すること」について発見したこと、感じたこと、ある考えに至ったことをまとめたものです。 端的に結論を書くと「発信しよう！」ということなのですが、そこに思い至った経緯なども合わせて読んでいただければ嬉しいです。 想定読者 エンジニアの（特に発信が苦手、嫌い、やったことない、という）方 発信を呼び掛けてる技術広報の方 テック企業に勤めている非エンジニアの方 SNSや社内ブログで発信をめちゃくちゃやっている方（レビュアーとして意見もらえたら嬉しいです） 簡単に自己紹介 はじめまして。Bambooこと竹中（ @shell_in_bamboo ）です。 7月にKINTOテクノロジーズに入社し、Fukuoka Tech Labの立ち上げと技術広報グループのマネージャーを兼任しています。 新卒で12年ほど独立系のSIerでエンジニアやPMを経験し、前職では福岡の金融機関の内製開発組織でスクラムマスターをやっていました。スクラムマスターってなにするの？とよく聞かれるのですが、「組織やチームのことを考えてる人」と最近では答えてます。あんまりよくわからねーですね。笑 マインドチェンジ さて、そんな私がKINTOテクノロジーズに入社して技術広報を担うことになったのですが、それまでは発信することに積極的ではありませんでした。 ちょっと前までの考え方 自己紹介で書いたとおり、前職までは組織やチームのことを考えて働いていたので「外に発信してる余裕なんてない！」という感じでした。イベントやセミナーで情報を仕入れることはあっても、自分から情報発信はほとんど行っていませんでした。 そういう役割をやっている人もいたし、向いている人がやるんだろうな～がんばれ～ありがとう～という考え方でした。 考え方がかわったタイミング ハッ！ ・・・としたタイミングはなかったです。どちらかというと、技術広報って何だろう？どうあるべきだろう？と調べたり考える中で徐々に変わっていった感覚です。 しかし、エンジニア時代の経験や、スクラムマスターとしての考え方が「発信すること」に確かにつながった感覚があります。 で、どう変わったの？ 「間違ってた！発信はやれたらやるものでもなく、やれる人がやるものでもなく、自分も含めみんながやった方がいい！」 です。 暑苦しいですね。一気に離脱者が増えそうです（技術広報としてビュー数を意識する私偉い）。 なぜそう思ったのか？ 1つ目は、エンジニア時代にたくさんの技術記事やブログに助けられた経験を思い出したからです。 何も技術がわからない新人時代、ある程度開発ができるようになってきたとき、PMとしてプロジェクトを管理していたとき・・・どんなときでも検索して出てくる先達や同士の情報に救われていました。これは、「発信してくれる」人がいなければ得られないものでした。 それにも関わらず、私自身は発信をほとんどせず、恩を返すこともできていなかったわけです。 2つ目は、スクラムマスターとして自分がアジャイルな行動をできていないことに気づいたからです。 簡潔に言うと「早くリリースして早く検証する」という考え方があるのですが、私は「早く」どころかリリース自体をしていなかったわけです。自分で良いと思ったものも、逆に良くないと避けてるものも、外に出してみないと正しいのかどうかわかりません。 私が独りよがりで信じたものをチームや組織の誰が受け入れるでしょうか。間違っていても、失敗しても、発信をして、フィードバックをもらうべきだったのです。 Learning in Public このブログを書くにあたり調べていると、"Learning in Public" という言葉が海外にはあることを知りました。 自分の学びの途中経過を公開しながら成長していく姿勢・文化のことを言うらしいです。 Learning in Publicの効果としては、以下のようなものが挙げられています。 学びの定着が圧倒的に早くなる。 人に伝える、教えることは理解をより深めることにつながります。説明する力もつきますね。 同じことで悩む誰かの助けになる。 失敗は悪いことではありません。誰かが失敗をシェアすることで同じ轍を踏む同士を救えます。エンジニアリングの現場では「自分の環境だけで起きているわけではない」という情報は重要なヒントにもなり得ます。 フィードバックがもらえる。 「自分は未熟だから」と発信を戸惑いますよね。けれど、未熟だからこそ発信をしてフィードバックを得て成長するチャンスを掴む、と前向きにとらえることができます。 他にもありますが、いくつかピックアップしました。この考え方は、まさに私が技術広報として今考えに至ったものでした。 アクションプラン 格好つけようとしてこんな見出し付けたらAI感出ますね。。安心してください、(手で)書いてますよ。笑 さてさて、どれだけマインドが変わっても、具体的な行動に移すのは難しいものです。かくいう私も、この投稿が今の会社に入って初投稿です。上司には秘密ですよ。（バレてる） 「いつだったらブログ書けるかな？？」 「仕事が落ち着きそうなときにイベント登壇しようかな・・・」 こんな感じで時期を見計らっていてはいつまで経っても先に進めません。目の前の仕事、割り込みの依頼などなどは、なかなか途切れることはないですからね(´・ω・｀) では、どうすればいいんでしょう。 発信する日を勢いで適当に決める 勢い？適当？そんなことでいいのか！ と、思われたでしょうか？ いいんです。 そんな真面目なあなたは、きっと決めた期限までに完成させるでしょう。笑 実はこれは「仕事の量は、完成のために与えられた時間を全て満たすまで膨張する」というパーキンソンの第一法則というものを逆手に取っています。 期限を先に決めることで、人はその期限に向かって頑張るわけですね。プロジェクトで先にリリース日を決めるのもこんな効果があったりします。 日付は、自分の中だけで決めるのではなく、ある程度強制力を持たせた方が効果的です。アドカレやイベントに登録してしまうのがわかりやすいと思います。 できるかどうかはさておき、まず、記念すべき発信の日を決めてみてください！ 発信するペースを決める 2つめの方法は、ペースを決めることです。 ペースを維持することで人はそれに慣れてきます。 余談ですが、スクラムのスプリントも、一定のペースを保つことが推奨 ^1 されています。 1ヶ月に1本ブログ書く！ とかだと、月初になったり月末になったりペースが狂うので、日単位ぐらいで固定化したほうがいいかなと思います。 おわりに ここまでお付き合いいただきありがとうございました。 こんなことを書いておきながら、まだまだ筆不精な面はありますし、億劫な気持ちも残ってはいます。 けれど、せっかくだから自分をアップデートしようと前向きな気持ちの方が大きいです。何よりも、少しでも世の中に還元できるようになれたら嬉しいというワクワク感があります。 次の記事が1年後とかにならないように頑張ります。笑 ではでは～

この記事は KINTOテクノロジーズアドベントカレンダー2025 の21日目の記事です🎅🎄 目次 1. メリークリスマス！2025年のAI活用推進を振り返って 2. 個人活用の成功と組織活用の課題 　 2-1. 個人活用普及率8割の達成 　 2-2. 組織的な活用とは 　 2-3. 業界全体の課題 3. イノベーションの二つの潮流 　 3-1. AIネイティブとAIドリブン 　 3-2. つまずきの4つのパターン 4. GenAIパラドックスの構造 　 4-1. 効率向上と収益の乖離 　 4-2. 属人性という課題 　 4-3. 視点の転換 5. 本質的な問いの立て直し 　 5-1. 汎用AIツールの特性 　 5-2. 技術導入前の課題整理 　 5-3. 再現性が高い既存フレームワークの活用 　 5-4. 人間中心のシステム思考の活用 　 5-5. つまずきの4つのパターンの正体 　 5-6. 問題発掘に有益だったこと 6. 実践的な解決アプローチ 　 6-1. 中長期と短期の両立 7. おわりに：本質的な価値創造へ メリークリスマス！2025年のAI活用推進を振り返って こんにちは！AI FirstグループでAI活用推進を担当しているShiori（ @shor_t8q ）です。企業のDX担当者、AI推進リーダー、そして「個人でのAI活用は進んでいるのに、事業や収益に関して期待した効果が出ていない」という課題を感じているすべての方へ、「組織のAI活用」と業務変革のヒントをお伝えできればと思います。 個人活用の成功と組織活用の課題 個人活用普及率8割の達成 2025年、私たちは「個人のAI活用」と「組織のAI活用」という両輪でAI活用を推進してきました。 まず社内の現状を共有します。社内AIツールのデータから、従業員のAI活用率は夏の時点で約8割に達しました。多くの社員がAIチャットツールやAIコーディングツールを日常的に活用し、個人の業務効率向上を実現することができました。 しかし、そこである気づきがありました。 「個人の効率は向上しているものの、組織としての成果が見えにくいのでは？」 そこで、組織的なAI活用推進をさらに強化することにしました。実際に取り組みを進める中で分かったのは、「組織的な活用」は「個人的な活用」とは異なる性質を持ち、異なるアプローチが必要だということです。 組織的な活用とは 組織的な活用とはどのような状態を指すのでしょうか。私たちはこう定義しました。 組織的なAI活用 （KINTOテクノロジーズ社内資料より） 複数グループや部門などが連携し、組織横断プロジェクトで、業務・開発プロセス・システムにAIを導入し、事業や収益に対して何らかのインパクトを与えること。 この定義に照らし合わせたとき、「組織的な活用が、想定以上に進まない」という現実に直面しました。 業界全体の課題 社外の動向を調べてみると、McKinseyの Seizing the agentic AI advantage に興味深いデータが掲載されていました。 特定のビジネス機能やプロセスに組み込まれた垂直的な活用事例の課題 （McKinseyレポートより） By contrast, vertical use cases—those embedded into specific business functions and processes—have seen limited scaling in most companies despite their higher potential for direct economic impact (Exhibit 2). Fewer than 10 percent of use cases deployed ever make it past the pilot stage, according to McKinsey research. 「対照的に、特定のビジネス機能やプロセスに組み込まれた垂直的な活用事例は、直接的な経済効果がより高い可能性があるにもかかわらず、ほとんどの企業では限定的なスケーリングしか見られていません。マッキンゼーの調査によると、展開された活用事例のうち、パイロット段階を超えるものは10%未満です。 出典: McKinsey "Seizing the agentic AI advantage" つまり、特定のビジネス機能やプロセスに組み込まれた垂直的な領域でAIを活用しようとしている企業の約9割が、パイロット段階（試験運用）を超えることができず、実証実験の段階で終わっている状況です。 これは「パイロット・パーガトリー（実証実験の煉獄）」と呼ばれる現象で、弊社だけの問題ではなく業界全体の傾向だったのです。 業界全体で「組織的なAI活用は容易ではない」という課題が報告されている状況です。私たちは、この課題に向き合うため、まずは社内の現状を分析することから始めました。 イノベーションの二つの潮流 AIネイティブとAIドリブン 社内の取り組みを俯瞰してみたとき、大きく分けて2種類のイノベーションラインがあることが分かりました。 AIネイティブ（AI Native） AIがあることを前提として、ゼロからプロダクトや体験が設計されているもの 仕組みの中に自然にAIが組み込まれている AIドリブン（AI Driven） 既存のシステムやプロダクトに、後からAIを組み込んでいくもの 既存業務や既存システムの一部をAIで代替・置換する取り組み ここで明らかになったのは、「AIネイティブな取り組みは比較的進んでいるが、AIドリブンは難航している」という傾向でした。 AIネイティブな領域では、社内のアーリーアダプターたちが相互にボトムアップで連携し、新しい価値を生み出してプロダクトやシステムをローンチすることが実現しています。一方、AIドリブン——つまり既存業務や既存システムの置き換え——は、関係者が多く抱えている問題も複雑で進めることが難しい現状があります。 つまずきの4つのパターン 社内の状況を整理していくと、AI活用で進捗が滞っているケースは、おおむね4つのパターンに分類できることが見えてきました。 1. 技術先行型（Tech First） 「新しい技術が登場したので、まず検証してプロトタイプを作成した」というケース。技術力のあるエンジニアが速やかに作成できるのですが、その後で「このプロトタイプをどこで活用すべきか」と、解決すべき課題を後から探すことになります。 2. トレンド先行型（Trend First） 「AIエージェントを使って〇〇を実現したい」というケース。手段（AIトレンド）が目的化してしまい、誰のどのような課題を解決するのかが明確になっていません。 3. 目的不明瞭型（Lost in Possibility） 「AIを使って〇〇を実現したい。ただ、何をすればよいのか分からない」。意欲はあるものの、入口で立ち止まってしまっているケースです。 4. 優先度判断困難型（Priority Paralysis） 「AIを導入して解決したい課題はある。今の技術であればさまざまな箇所に適用できそうだ。ただ、何から手をつければよいか迷う」。適用すべき箇所の目利きはできているが、どこから着手すべきか判断できず、可能性（適用範囲の幅や深さ）の中で方向性を見いだせないパターンです。 さらに、これらとは別の軸で、「AI環境整備の課題」も存在しました。「AIを活用したいが、方針・ルールの整備がAIに最適化されていないので意思決定ができない」、「利用したいデータが集約されていない」といった、ガバナンス、インフラ、リソースの問題で進捗が滞るケースです。 ※「AI環境整備の課題」は範囲が広いので、今回の記事ではこのテーマには言及しません。 上記パターンは、各々解決しなければプロジェクトは前に進みません。私は、組織として「AIプロジェクトの推進モデル」を構築する必要性を感じました。 GenAIパラドックスの構造 効率向上と収益の乖離 この1年、現場の状況を確認する中で GenAIパラドックス と呼ばれる現象を実感してきました。これは、「AIによって個人の業務効率は確実に向上しているのに、組織としての収益や成果には必ずしも直結していない」という状況です。 「GenAIパラドックス」について、McKinseyの Seizing the agentic AI advantage では、以下のように定義されています。 GenAIパラドックスとは？ （McKinseyレポートより） 「10社中8社近くがGenAIを何らかの形で導入していますが、ほぼ同じ割合の企業が収益に大きな影響はないと報告しています。私たちはこれを『GenAIパラドックス』と呼んでいます。」 "Nearly eight in ten companies have deployed gen AI in some form, but roughly the same percentage report no material impact on earnings. We call this the 'gen AI paradox.'" 出典: McKinsey "Seizing the agentic AI advantage" なぜ、このパラドックスが発生するのでしょうか。弊社の分析から、いくつかの要因が浮き彫りになりました。 取り組みの断片化 : 個別の検証や単発の取り組みになっており、体系的に繋がっていない デリバリーモデルの未定義 : 「どのように価値を届けるか」という型が確立されていない ガバナンスと整備不足 : AIを受け入れるための基盤（ルール、インフラ、データ、プロセス）が整っていない McKinseyの Seizing the agentic AI advantage でも、同様の内容が言及されています。 属人性という課題 さらに根本的な問題として、 業務の言語化不足 があります。 現在のAI技術、例えばAIエージェントを業務ワークフローに組み込もうとすると、そのワークフロー自体が明確に定義され、言語化されている必要があります。しかし、多くの現場では「ここはAさんの判断で」「ここはBさんの経験則で」といった、人間の判断（属人性）で運用されている部分が非常に多いのです。 「AIを導入したい」と考えても、AIは「暗黙知」を理解することができず、属人的になっている領域には、そのままではAIを適用できません。 まず業務を整理し、定義し直す必要があります。ここに至る組織的認知、具体的なアクションプランをステークホルダーで合意形成し、着実に進めていかなければいけないということが、AI活用の大きなハードルとなっていたのです。 視点の転換 そこで、私は 「AIを導入したからといって、イノベーションが加速するわけではない。イノベーションを加速させるために、AIを活用するのだ」という視点の転換が必要なのだと考えるようになりました。 本質的な問いの立て直し 汎用AIツールの特性 ChatGPT、Gemini、Claudeのような、いわゆる「汎用的なAIチャット」は非常に高性能です。相談すれば、速やかに質の高い解決策を提示してくれます。 しかし、ここに注意すべき点があります。AIは、私たちが投げかけた質問には答えてくれますが、「デフォルトのチャットウィンドウでは、私たちが抱える問題の深掘りまでは行わない」のです。 ただし、これは汎用AIチャットをデフォルト設定のままで使用した場合です。深掘り機能を持つAIエージェントを構築し、そのAIと対話することで、問題を探索する質問を引き出し、課題を整理できることは既に実証済みです。 ユーザーが「これを作りたい」と伝えたとき、AIは素直に作成方法を提案します。しかし本来は、「なぜそれを作りたいのですか？」「もっと本質的な課題は別にありませんか？」といった、コンサルタントのような深掘りこそが必要な場面が多々あります。 技術導入前の課題整理 「できる・できない」ではなく「誰に・どのような価値か」 例えば、「社内のお問い合わせの対応が大変なので、お問い合わせをAIで対応できるようにしたい」という相談が現場から寄せられたとします。これに対して、すぐに「RAG（検索拡張生成）を使って社内Wikiを読み込ませたチャットボットを構築しましょう」と提案するのは容易です。しかし、それでは本質的な解決にならないことがあります。 ここで私たちは問い直す必要があります。 「そもそも、なぜお問い合わせが発生するのか？」 「マニュアルが分散していて知りたい情報にアクセスできないことが原因ではないのか？」 「あるいは、〇〇についてマニュアルはあるが、従業員が判断しにくい内容になっていることが原因ではないか？」 もし後者であれば、AIに回答させる前に、マニュアルの内容を更新するのが適切かもしれません。マニュアル精度が高くないと、AIがハルシネーション（誤った情報）を生成するリスクが高まります。 再現性が高い既存フレームワークの活用 「問題の特定」、「課題定義」と「合意形成」を進める上で、私たちがAIプロジェクトにおける課題整理で採用したアプローチは、「デザイン思考」や「システム思考」などの世の中で既存の課題解決フレームワークです。 デザイン思考 （Design Thinking）は、ユーザーへの共感をベースにした人間中心アプローチです。ユーザーニーズを深く理解し、反復的なプロトタイピングを通じて創造的な解決策を生み出します。 一方、 システム思考 （Systems Thinking）は、要素間の相互関係と全体最適を重視し、複雑な組織システムの根本原因を特定します。 デザイン思考とシステム思考を組み合わせることで、個々のステークホルダーの課題（デザイン思考）と、それらが生じている業務や組織全体の構造的問題（システム思考）の両方に目を向けられます。この融合は、関係者の認識を合わせるための有効な手法と成り得るという仮説を持ちました。 人間中心のシステム思考の活用 私たちは複数のプロジェクトにおいて、 デザイン思考 と システム思考 を組み合わせた「人間中心のシステム思考」というアプローチを導入しました。これは、ユーザーへの共感をベースに関係者と信頼関係を築きながら進める創造的なプロセスとシステム全体を俯瞰し、問題構造を把握する分析的な視点を融合させたものです。 このアプローチにより、以下のことが可能になります： 視点の切り替え : システム全体と個々のステークホルダー、両方の視点を行き来できる 共感の醸成 : 人々の課題だけでなく、システム自体が抱える構造的な問題にも目を向けられる 行動変容の促進 : 根本原因を理解した上で、効果的な介入ポイントを設計できる 組織におけるAI活用の課題は、まさに「人間システム」の問題です。複数のステークホルダーが絡み合い、それぞれが異なるニーズや制約を抱えています。人間中心のシステム思考は、この複雑性に対処するための有効な課題解決手段となりました。 デザイン思考 と システム思考 の違いを知りたい方は、 Systems Thinking vs Design Thinking, What’s the Difference? の記事が参考になります。 つまずきの4つのパターンの正体 人間中心のシステム思考を用いた課題解決では、以下のステップで進めることが効果的です。 ユーザー・ステークホルダーへの共感（Empathize with Stakeholders） : 関係者へのヒアリングや観察を通じて、現場の状況を深く理解する 問題の発掘（Discover Problems） : 顕在化している問題だけでなく、対話を通じて潜在的な問題も引き出す システム構造の分析（Analyze System Structure） : システム思考を用いて、問題の真因や要素間の関係性を特定する 課題の定義（Define Issues） : 取り組むべき課題を整理し、優先順位をつける 解決策の検討（Design Solutions） : 課題に対する解決アプローチを設計する 技術選定（Select Technology） : AI、インフラ、ツールなど最適な技術スタックを選定する プロトタイプ構築（Build Prototype） : 小さく素早く動くものを作り、仮説を検証する 反復と拡大（Iterate & Scale） : アジャイル開発プロセスに基づき、フィードバックを取り入れながら改善・拡張を繰り返す つまずきの4つのパターンは、6（技術選定）や7（プロトタイプ構築）からスタートして行き詰まり、1（ユーザー・ステークホルダーへの共感）~5（解決策の検討）を考え始めるというプロセスになっていることがわかりました。 AIによってプロトタイプを構築しやすくなった反面、従来のプロダクト開発で定義していた1（ユーザー・ステークホルダーへの共感）〜5（解決策の検討）がスキップされる傾向があるため、「システムは構築できたが、誰かの具体的な問題を解決しているわけではない」という状況が見えてきました。 ※社内では、6（技術選定）や7（プロトタイプ構築）からスタートし、1（ユーザー・ステークホルダーへの共感）〜5（解決策の検討）を経て、成功しているケースも複数あるので、6（技術選定）や7（プロトタイプ構築）からスタートするプロトタイプドリブンのアプローチも有効だと実証されています。そのため、6（技術選定）や7（プロトタイプ構築）からスタートすることがネガティブな要素というわけではありません。あくまで傾向の話です。 しかし、6（技術選定）や7（プロトタイプ構築）からスタートすることで、「採用した技術や構築したプロトタイプを活かしたい」という潜在的なバイアスが先行し、1（ユーザー・ステークホルダーへの共感）〜5（解決策の検討）のプロセスを、後から中立的に進めることが難しくなることに留意する必要があります。 問題発掘に有益だったこと フレームワークを導入したからといって、すぐに問題解決がスムーズになるわけではありません。まずは、関係者とシステム全体の課題整理を行う必要がありました。最初にワークショップを行い、ステークホルダーが抱える問題をデジタルホワイトボードで整理しようと試みたのですが、想定以上に難航しました。 原因を分析すると、関係するステークホルダーが多く、問題を引き起こしている要素が複数あるような複雑性が高い問題は、言語化のハードルが高いため、ホワイトボード上に網羅的に問題を書き出すことが難しいということがわかりました。 そこで、ホワイトボード形式ではなく、2on2や1on2でヒアリングを実施し、対話を通して潜在課題まで発掘できるようなコミュニケーションアプローチを取りました。 結果として、グループや部署を横断するような業務改革を行うときは、最初は対話を通じて信頼関係を築くことが重要であり、次に対話を通して問題発掘を行い、関係者の問題解像度が上がってきた時点で、適宜ワークショップを実施して課題を整理することが効果的だということがわかりました。 実践的な解決アプローチ 中長期と短期の両立 とはいえ、「業務フローや課題を全て整理してからAIを導入しましょう」と言っていたら、プロジェクトの推進が遅れてしまいます。そこで私たちは、「中長期」と「短期」を分けて、並行して進める戦略を推奨しています。 アプローチ 目的 アクション 中長期（Slow） 本質的な課題解決、方針策定 組織全体の課題整理、ワークフローの再定義、関係者との合意形成 短期（Fast） スピード感、現場の改善 目の前の明確な課題に対して、AI技術を適用し、プロトタイプを作成し、改善を繰り返す 全体の方針を策定しつつ（中長期）、現場では迅速に改善を回していく（短期）。この両軸で進めることで、スピード感を維持しながら、点と点を線に繋げていくことができます。 おわりに：本質的な価値創造へ 最後に、2025年の1年で得た最も重要な学びを共有します。 「AIを活用すること自体を、目的化してはいけない。」 「AIで何ができるか」よりも、「私たちが本当に解決すべき問題は何か」「それを解決したとき、誰にどのような価値があるのか」——この原点に立ち返ること。そして、その価値を最大化するために、AIの 人間の能力を拡張する力 や 処理速度を向上させる力 や 数や量を出す力 をどう活用するかを考えることが重要だと気づきました。 AI導入は、単なるツールの活用ではありません。それは、私たちが自分たちの仕事のやり方、ひいては 本質的な価値 を見つめ直す過程でもあります。組織的AI活用のハードルが「自分たちの業務の未定義さ」や「目的の曖昧さ」や「問題の真因を見極める力」にあると認識できれば、乗り越える方法は必ず見つかります。特にAI活用の問題は技術ではなく、業務、人と組織、マインド、仕組みやルールにあるケースがほとんどです。 今回の考察が、同じ課題に取り組む皆様の参考になれば幸いです。 2025年は技術革新の激動の中、皆様大変お疲れ様でした！ 2026年もさらに未知な技術や概念が現れるかもしれませんが、共に頑張りましょう！ Made with Drive♥️

この記事は KINTOテクノロジーズアドベントカレンダー2025 の20日目の記事です🎅🎄 はじめに こんにちは、KINTOテクノロジーズ Mobile KMPチームです。 本記事は「Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ」シリーズのPart 2です。Part 1ではハイブリッド開発を選んだ背景とアーキテクチャ概要を紹介しました。今回は具体的な実装方法を詳しく解説します。 本シリーズの構成 Part 1：なぜハイブリッドなのか Part 2：実装ガイド ← 現在の記事 Part 3：SwiftUI連携と技術Tips（近日公開） 実装事例 プロジェクト構造 プロジェクトのディレクトリ構成 my-cmp-app/ ├── composeApp/ │ ├── src/ │ │ ├── commonMain/ // CMP Shared code │ │ ├── androidMain/ // Android-specific │ │ └── iosMain/ // iOS-specific ├── iosApp/ │ ├── Views/ // SwiftUI views │ ├── Screens/ // Native screens │ └── ComposeViewContainer.swift └── shared/ // KMP domain layer ├── viewmodels/ └── models/ まず composeApp です。 commonMain にはCMPの共通コード、 androidMain / iosMain には各プラットフォーム固有の実装を入れています。 次に iosApp 。SwiftUIのViewやネイティブ画面が含まれています。特に ComposeViewContainer.swift ファイルでCMPコンポーネントをiOS側に組み込んでいます。 最後に shared 。KMPのドメイン層で、viewmodelsやmodelsを共通化しています。 このように、ディレクトリレベルでも 共通化できる部分はまとめ、ネイティブ依存部分は分離 しています。 ハイブリッドUIの実例 実際に作成したPoCアプリの画面構成を紹介します。 MainScreenでは、ボトムナビゲーションに4つのタブを配置しています。 タブ UI実装 Application CMP Lineup CMP HelpCenter CMP Settings SwiftUI on iOS Application、Lineup、HelpCenter はCMPで共通UIを実装 Settings だけはネイティブ（iOSではSwiftUI）で作っています このように、共通UIとネイティブUIを組み合わせても、タブ切り替えはシームレスに行えます。 iOS固有のUIが活きるSettings Tab ネイティブからCMPベースのハイブリッドナビゲーションへの移行 このような構成では、ネイティブ中心のナビゲーションからCMPベースのハイブリッドナビゲーションへ移行する必要がありました。どのように移行したのか、具体的な方法をご紹介します。 既存のナビゲーションスタックをリファクタリングし、ネイティブとCMP間でルーティング プラットフォーム固有のナビゲーションロジックを共有インターフェースの背後に抽象化 ルートベースのナビゲーション戦略 先ほど紹介したPoCアプリのタブ構造を振り返ると、1〜3番目のタブはCMP、4番目はSwiftUIで実装しています。 PoCアプリのタブ構造 このような構成でルーティングを実現するために、各画面のルートをstring constantで定義しておきます。 // Routes.kt - Navigation routes defined in shared code object Routes { const val LOGIN = "login" const val SCREEN_A = "screen_a" const val SCREEN_B = "screen_b" const val SCREEN_C = "screen_c" const val SCREEN_D = "screen_d" } プラットフォームごとに実装を分けて、AndroidではCompose Navigation、iOSではSwiftUI NavigationでComposeをつなぐ Bridge をします。 Kotlinナビゲーション実装 こちらは ComposeViewController.kt の例です。パラメータとして initialRoute を受け取り、そのルートに応じてwhen分岐で 遷移先を切り替え ています。 // ComposeViewController.kt fun createComposeViewController( initialRoute: String, onCallback: (Boolean) -> Unit = {} ): UIViewController { return ComposeUIViewController { MyAppTheme { when (initialRoute) { "login" -> LoginNavigation(onLoginSuccess = onCallback) "screen_a" -> ScreenANavigation() "screen_b" -> ScreenBNavigation(iosCallback = onCallback) "screen_c" -> ScreenCNavigation() "screen_d" -> ScreenDNavigation() else -> FallbackNavigation() // default fallback } } } } 例えば、"login"なら LoginNavigation へ、"screen_a"や"screen_b"なら、それぞれの画面のNavigationを呼び出します。このように、ルートを定義しておけば、プラットフォーム固有のナビゲーション処理と簡単に接続できます。 iOS側でCompose Navigationを統合する仕組み まず ComposeViewContainer を定義して、 UIViewControllerRepresentable を実装します。これによってSwiftUIの中に Compose UIを埋め込む ことができます。 // ComposeViewContainer.swift struct ComposeViewContainer: UIViewControllerRepresentable { let initialRoute: String let onCallback: (Bool) -> Void func makeUIViewController(context: Context) -> UIViewController { // Wrap the Swift callback into the KotlinBoolean signature let kotlinCallback: (KotlinBoolean) -> Void = { kotlinBool in onCallback(kotlinBool.boolValue) } // Create the Compose UIViewController, passing the wrapped callback return ComposeViewControllerKt.createComposeViewController( initialRoute: initialRoute, onCallback: kotlinCallback ) } func updateUIViewController(_ uiViewController: UIViewController, context: Context) { // No dynamic updates needed here } } 次に、 makeUIViewController の中でKotlin側の createComposeViewController を呼び出します。 iOS Navigationの実践 こちらは、統合コードを使ったiOS Navigation codeです。 TabView の中に4つのタブを定義しています。1〜3番目のタブは CMP画面 で、 NavigationView の中に ComposeViewContainer を埋め込み、初期ルート"screen_a"を指定しています。 // MainScreen.swift struct MainScreen: View { var body: some View { TabView { // Tab 1~3: CMP screen NavigationView { ComposeViewContainer(initialRoute: "screen_a", onCallback: { _ in }) }.tabItem { Label("Application", systemImage: "doc.plaintext") } ... // Tab 4: SwiftUI screen NavigationView { SettingsScreen() }.tabItem { Label("Settings", systemImage: "gearshape.fill") } } } } 4番目のタブはSwiftUIネイティブの SettingsScreen() を使用しています。このように、CMPとネイティブ画面を同じナビゲーション構造内で自然に共存させることができます。 Koinによるモジュール化 ここまでナビゲーション統合を見てきましたが、実際のアーキテクチャはCMP + MVVMでどんどん複雑になります。そこで、Multiplatform向けDIの Koin を導入しました。結果、構造がシンプルになり、テストや保守もしやすくなりました。 Koinの利点： 依存関係をきれいに管理 できる 同じ定義を使って 複数プラットフォームで再利用 できる モジュール単位で分離 でき、構造がシンプルになる テストのしやすさ が向上 // commonMain/di/AppModule.kt val appModule = module { single { NetworkClient() } single { AuthRepository(get()) } viewModel { HomeViewModel(get()) } viewModel { ProductViewModel(get()) } factory<Validator> { ValidatorImpl(get(), get()) } } single や viewModel をシンプルに書くだけで、依存関係を自動的に解決できます。 プラットフォーム固有のDI Koinでは、iOSとAndroidそれぞれに 専用のモジュール を定義できます。 // iosMain/di/PlatformModule.ios.kt val iosModule = module { single<HttpClientEngine> { Darwin.create {} } single<DataStore<Preferences>> { createDataStore() } single { IOSLocationService() as LocationService } single { AppStoreConnectTracker() as AnalyticsTracker } } // androidMain/di/PlatformModule.android.kt val androidModule = module { single<HttpClientEngine> { OkHttp.create {} } single<DataStore<Preferences>> { createDataStore(androidContext()) } single { AndroidLocationService() as LocationService } single { FirebaseAnalyticsTracker() as AnalyticsTracker } } iOS側では iosModule を定義し、 Darwin.create() を使った HttpClient を登録しています。一方Android側では androidModule を定義し、 OkHttp.create() を使った HttpClient を登録しています。 このように、 プラットフォーム固有の実装はモジュールごとに分離 しながら、共通のインターフェースを通して利用できるようにしています。 Koinの初期化 ここではKoinの初期化方法です。まず共通コード側に initKoin 関数を用意しておきます。 // commonMain/di/KoinSetup.kt fun initKoin(platformModule: Module) = startKoin { modules(appModule, networkModule, platformModule, ...) } // Android Application class class MyApplication : Application() { override fun onCreate() { super.onCreate() initKoin(androidModule) } } Androidでは Application クラスの onCreate から androidModule を渡して初期化します。 // iOS AppDelegate func application(_ application: UIApplication, didFinishLaunchingWithOptions...) { KoinKt.doInitKoin(platformModule: IOSPlatformModuleKt.iosModule) return true } iOSでは AppDelegate から iosModule を渡すだけです。このようにして、 両方のプラットフォームで同じ初期化処理を共通化 できます。 Koinでの動的モジュールロード 次に、Koinでの 動的モジュールロード です。 // Feature module definition val featureModule = module { viewModel { FeatureViewModel(get(), get()) } factory { FeatureValidator() } single { FeatureRepository(get()) } } // Register dynamically after the Koin's initialization loadKoinModules(featureModule) まず featureModule を定義して、ViewModel・Validator・Repositoryを登録します。その後、 loadKoinModules に featureModule を渡してロードします。 Koin初期化後にモジュールを動的にロード できます。これにより、大規模アプリでも 必要な機能だけを後から読み込む構成 が可能になります。これがKoinの強みです。 開発効率化事例：Validator統合 問題状況 メール、電話番号、郵便番号、パスワード強度、日付形式など、様々な検証ロジックが必要でした。 従来方式で実装した場合： Android：24個のValidator（Kotlin） iOS：24個のValidator（Swift） 合計48個の実装 合計48個のValidationResult 合計48セットのユニットテスト KMPソリューション すべての検証ロジックを共有KMPモジュールに移動しました。 Kotlinで各Validatorを一度だけ実装 共通関数/クラスとして公開 CMP画面、Android/iOSネイティブ画面すべてから呼び出し可能 結果： 実装量50%削減 テストコード50%削減 プラットフォーム間検証ロジックの一貫性保証 バグ修正も一箇所で完了（両OS同時に修正される） 次回予告 Part 2では、プロジェクト構造、ナビゲーション統合、Koin DI、Validator統合など具体的な実装方法を紹介しました。 Part 3：SwiftUI連携と技術Tips では、SwiftUIとCMPの相互埋め込み、CMP vs Flutter比較、実践で直面した落とし穴、導入戦略などを詳しく解説します。お楽しみに！ こちらは「Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ」シリーズのPart 2です。