#kintone100日チャレンジの結果｜100日で変わったAI開発と、終了後1か月の成果

#kintone100日チャレンジでは、2026年4月1日から7月9日までの100日間、毎日1テーマを扱って完走しました。全100日分の記事と概要動画も制作しています。

100日で得た最大の成果は、100件を試作したことだけではありません。AIにコードを依頼する使い方から、役割、必要な資料、確認工程、人が判断する境界を決めて開発する使い方へ変わりました。

Day1からDay100までのテーマ、記事、成果物の概要動画は、次のアーカイブにまとめています。

あわせて読みたい

【#kintone100日連続チャレンジ】AIにkintoneカスタマイズを100%任せたらどこまでいけるか？現役フリーランスの「100 Days of kintone Hacks」始動！

森田ユウゴ

台湾で「面倒解決エンジニア」として活動している森田ユウゴです！

「面倒くさい！」を原動力に、kintoneカスタマイズやChrome拡張機能開発などを通して、日常や業務の課題をテクノロジーで解決することに注力しています。

• 2025年12月 kintone認定 アプリデザインスペシャリスト取得
• 2026年01月 kintone認定 カスタマイズスペシャリスト取得

ココナラやクラウドワークスなどでご相談いただけます！
下記のお問い合わせフォームからお気軽にご相談ください▼

森田ユウゴへお問い合わせ(Google Formに移動します)

kintone100日チャレンジで掲げた目標は達成できたのか

開始時に掲げた7つの目標のうち、6つは実施し、1つはチャレンジ中に方針を変更しました。100日前の宣言と結果を一つずつ照らし合わせると、次のとおりです。

100件には、試作で終えたものや、検証後に既存手段を選んだものも含まれます。100件すべてを製品品質や業務導入実績として数えるのではなく、100日分の試作と判断の記録として扱っています。

ここまで記載のとおり、#kintone100日は宣言通り成功したと言っても良いと考えています。

100日間でAI環境と開発の進め方はどう変わったか

100日間の変化は、一直線ではありませんでした。

数時間かけて手探りした序盤、AIエージェントの構築に手応えを感じた中盤、やる気やアイデアが尽きた終盤を経て、最後は100回の試行錯誤を開発基盤へまとめています。

全体の概要

まず、100日間の変化を8つの時期に分けて俯瞰します。

Day1〜14：手探りの試行錯誤

序盤は、作りたい機能のイメージをAIへ伝え、出てきたコードを見ながら直す開発です。毎回CLIでプロジェクトを初期化し、必要なパッケージを導入するところから開始。1テーマに数時間、機能を詰め込んで半日を使う日もありました。

Day7は実用性に疑問が残る結果。Day12のpdfmeを使った帳票生成は、既存ライブラリや日本語フォントへの理解が足りず、ほぼ一日を費やしました。以来、私は実装前に既存手段と制約を調べ、1日で確認する範囲を先に決めています。

森田ユウゴ

振り返ると、この時期は悪い意味での「バイブ」コーディングです。作りたい画面はイメージしていても、採用する技術や確認方法を決めないまま進めていました。

開始前から、AIが参照する手順書や指示（AI向けスキル）は使っていたものの、ファイルへ書いて置くだけ。kintoneカスタマイズスペシャリストとしてJavaScript APIの使い方は指示できても、AIが毎回同じ基準で参照し、確認できる形には最適化できていません。

Day15〜30：公開責任とAI環境の転換

Day15を境に、速く作って広く公開することより、業務で使える範囲を判断することを優先しました。コードの全面公開をやめたのは、その判断を行動へ移した最初の転換です。

Day19前後にはCodexを試し始め、Day30の記録ではほぼ主力になっていました。Geminiで題材を整理し、CursorやClaude Code、Codexへ実装や確認を分けるなど、一つのAIへ全部を頼む使い方から離れています。

開始前は、複数のAIへ役割を与えて会社のように動かす使い方を半信半疑で見ていました。kintoneプラグイン開発へ落とし込む中で、実装役と評価役を分ける工程として試し始めています。

まだ前日のプロジェクトをコピーして修正する継ぎ足しも残っていました。一方で、AI向けスキルの差分を見ながら更新する試みも始めています。

Day31〜49：連続記録を守る制作体制

この時期から、チャレンジは毎日の勢いだけで続けるものではなくなりました。終日外出する日の分を前日に制作し、記事、概要動画、X投稿までを一つの工程として管理しています。

当初は前日制作をルールから外れるように感じていました。しかし、私生活や顧客作業と両立しながら100日を完走するには、制作日を調整しても公開を止めない方が重要です。公開宣言と、連続記録を途切れさせたくない気持ちが、制作工程を整えるきっかけになりました。

Day40前後からは、コーディングガイドラインをAIに読ませ、毎回同じ基準で確認することにも比重を移しました。ルールを書くだけでなく、開発工程の中で参照される状態へ変えています。

Day50〜59：ネタ切れとコンテキスト設計

折り返しを過ぎると、実装よりも次の題材を決める方が難しくなりました。cybozu developer networkのCybozu CDNやkintoneの基本機能を復習してみても、毎日価値のある案が見つかるわけではありません。
「ネタが尽きた」と感じながら、過去の業務で不便だった場面を掘り起こしました。

Day53では、kintoneの情報をAIへ渡すための「AIコンテキストビルダー」を試作しています。単発のプラグインを増やすだけでなく、AIが必要な情報を受け取る方法そのものを作る発想です。この試作が、Day100のコンテキスト管理へつながりました。

Day60〜70：エージェント構築が実用段階へ

Day60を超えたころは、「もう何でもできそう」と感じていました。前日のプロジェクトをコピーして継ぎ足す状態から、AIエージェント体制で実装、評価、修正の役割と、読むルールを再利用する状態へ進んだからです。

Day69では、データ入力をゲーム感覚で進めるゲーミフィケーション入力支援まで扱いました。kintoneの画面を少し変える題材だけでなく、利用者の行動を変えるテーマにも手を伸ばせています。このころには、プロジェクトの初期化やAI向けスキルを共通化する作業が進み、Day99でCLIへまとめる対象が見え始めていました。

Day71〜90：倦怠期を仕組みで越える

正直に言うと、残り約1か月のラストスパートに入ったこの時期は、100日間で一番やる気が出ませんでした。「もう何でも作れる」という自負もあり、インフラSEの経験を生かして、AIエージェントによるバックエンドのコード化にも着手した時期です。

ただ、100日チャレンジとしては「毎日新しい題材を出して発信する負荷」の方が目立つようになりました。

Day81では、動画とXを公開した一方、記事が下書きのまま残る工程漏れも起きました。続ける意志だけでは、複数媒体の公開作業を守れません。制作、確認、公開をチェックできる運用へ変える必要があると分かった時期です。

森田ユウゴ

「何やってるんだろう…」と惰性で続けてました。

この時期は、隣の芝生が青く見えるように、kintoneより別のプロダクトの方が魅力的に見えた時期です。そこでkintone以外のプロダクトにヒントを求め、Day88ではSalesforceを題材にプラグインを作りました。

それでも連続記録は止めませんでした。気分が乗る日だけAIを使うのではなく、役割と確認順を決めた工程があったから、手を動かし続けられました。

Day91〜98：ネタを絞り出しながら終わり方を考える

森田ユウゴ

海外でkintoneを使った経験まで、ついに題材にしてしまった。残るは何だろうか……。

Day87の翻訳プラグインとDay88の多言語名称は、海外でkintoneを使う中で感じた不便を題材にしました。企業向けの開発候補として温存していた、私にとっての「秘蔵ネタ」です。

Day91以降は、ほぼネタが尽きた状態から題材を絞り出していました。

一方で、AIへ役割を与えて開発する方法は、kintone以外でも使えるという手応えが出ています。

この時期はFableを使う別のAI開発に没頭し、ElectronによるWindowsアプリへ関心が広がった時期です。Day97に残り3日だと気づいた時点で、初めて触る技術でも、役割と確認工程を決めてAIと試せる状態でした。

Day99〜100：100回の経験を開発基盤へまとめる

Day80を過ぎたころから、「どう終わろうかなー」と考えていました。最後に選んだのは、もう一つプラグインを増やすことではなく、100回の試行錯誤を次の開発へ残すことです。

Day99では、プラグインの作成、テスト、パッケージ化、AI向けルールの同期をまとめた開発環境を作りました。Day100では、kintoneの設定、変更履歴、Git差分をAIと確認するためのコンテキスト管理へ進んでいます。

あわせて読みたい

kintoneプラグイン開発環境をNode.js製CLIで仕組み化｜Vite・TypeScript・AI同期まで

あわせて読みたい

kintoneをClaude Codeで分析する自作kint-originツール｜AIコンテキスト管理で設定・履歴・差分を追う

100日で変わった進め方をkintoneエンジニアとしてどう活かすか

現在は、kintoneを土台にAIを活用して問題を解決するエンジニアとして、実装前の手段選びから本番反映後の運用までを考えています。100日で変えた進め方を振り返ると、軸は「選択」「順次」「繰り返し」の3つでした。

選択：基本機能・既存製品・個別開発から適切な手段を選ぶ

個別カスタマイズへ進む前に、kintoneの基本機能や既存製品で要件を満たせない理由を確認します。課題や運用に合う手段が別にあるなら、AIで作れることを理由に個別開発を選びません。100件を試作する過程で、作らない判断も成果になると学びました。

AIエージェントは、要件を限定しないと必要以上に機能を盛り込んだり、過剰なテストを提案したりします。そのため、要件と利用規模に応じて、作る範囲と検証水準を先に決めます。

順次：AIに役割と工程を与え、決めた順番で進める

要件整理、実装、評価、人の判断という順番を決め、各工程のAIに役割、必要な情報、成果物、評価方法を与えます。不足情報、テスト失敗、費用の発生、破壊的な変更が見つかった場合は、その場で止めて人へ判断を戻します。

サブエージェントで担当を分け、フックで工程の前後を確認し、評価に通らない成果物は修正へ戻します。こうした仕組みは、AIが勝手に先へ進まず、決めた順番と停止条件に沿って仕事を進めるために使っています。

繰り返し：検証と改善を回し、次の開発へ残す

期待した結果と実際の動作を比べ、問題があれば修正し、もう一度検証します。基準を満たすまで「検証、修正、再検証」を繰り返し、コードが一度動いただけでは完了にしません。

検証結果、本番へ反映する条件、運用方法、問題が起きたときの戻し方を記録します。なぜその手段を選び、どこまで確認したかを引き継げる形で残すことで、次の開発を前回の経験から始められます。

「選択・順次・繰り返し」は、AI時代に新しく生まれた方法ではありません。プログラミングとプロジェクトマネジメントの基本に立ち返ったものです。

振り返ると、100日間で行ったのは、SIerとして経験してきた要件整理、役割分担、確認基準、差し戻し、引き継ぎをAI相手にも適用することでした。相手が人からAIに変わっても、仕事を安全に前へ進める基本は変わりません。

#kintone100日チャレンジ終了後1か月で形になった成果

手段を選び、工程の順番を決め、検証と改善を繰り返す進め方は、終了後1か月でkintone以外の制作にも広がりました。キャラクター、Ankiテンプレート、ゲームとWindowsアプリ、バックエンド基盤へ、それぞれ違う形で持ち出しています。

LINE「いつも可愛い子ブタのジーナ」―スタンプ6作品と絵文字1作品を公開

終了後1か月で形になった公開成果の一つが、LINE「いつも可愛い子ブタのジーナ」です。kintone開発で試してきた役割分担と確認工程を、画像制作へ持ち出しました。

2026年8月8日時点で、LINE STOREにはスタンプ6作品と絵文字1作品を公開しています。次の7枚から各作品のLINE STOREを確認できます。

初期の制作では、手足などの仕様差を見落とした画像を採用したことがありました。そこで、ジーナの体型、色、線、構図をまとめた基準画像と仕様書を用意し、生成と評価を別工程へ分けています。

生成担当は基準画像と制作指示を読み、1案を作った時点で止まります。評価担当は基準画像と並べ、キャラクターの同一性、手足のつながり、依頼内容、描画、納品条件の順に確認します。見た目が魅力的でも、ジーナとしての仕様に合わなければ採用しません。

背景透過やLINE向けサイズの検証は、その後の工程です。テーマ、採用画像、タイトル、メイン画像とタブ画像、公開の最終判断は私が担当しています。

マジナライフ Flashcard Studio

Ankiテンプレートの開発は、100日チャレンジ以前から続けていました。ココナラで依頼を受け、要望を聞き、個別に開発してリリースする工程では、私がすべての判断を抱えることがボトルネックでした。

そこで、ヒアリング内容を仕様へ変換し、生成、検証、リリースを分けた開発体制を整えました。その工程で完成済みのAnkiテンプレートを提供しているのが「マジナライフ Flashcard Studio」です。

あわせて読みたい

【Anki対応】テンプレートストアを開設しました｜無料apkg版をダウンロードできます

未経験分野への挑戦―9RABBITS（ナイラビ）とElectron

100日で試した役割分担と確認工程を、未経験だったゲームとデスクトップアプリへ持ち出しました。

9RABBITS（ナイラビ）

1から9の数字を順にタップし、うさぎをつかまえる脳トレゲームです。2026年8月8日時点ではv0.2.0の開発中で、Phaser 3、TypeScript、Vite、Capacitorを使い、WebとAndroid実機で動かしています。企画、実装、評価を分け、ソースコードを見ない評価役が実際に動かして遊びやすさを確かめる工程も試しています。

Electron製Notionタスク管理ツール

NotionのTasksDBをWindowsから操作する常駐アプリです。Electronは初めて扱うフレームワークでしたが、ReactとTypeScriptの経験を再利用し、Claude CodeとCodexが共通の開発ルールを参照できる構成にしました。Notion APIの認証情報を画面側へ渡さない設計も確認しています。

どちらもTypeScriptで開発し、kintoneプラグインで培ったAI駆動開発の経験を再利用しています。ゲームのPhaserとデスクトップアプリのElectronは、今回初めて扱うフレームワークです。

AI BackendとInfrastructure as Code

「AI-BackEnd-Management-System」では、約10年のITインフラ経験をInfrastructure as Code（IaC）へつなげています。変更管理、最小権限、監視、復旧について人が判断してきた内容を、AIが参照できるルールと記録へ翻訳する取り組みです。

CloudFormationでAWSの構成をコードとして管理し、実施内容と結果を残す作業記録、構成変更ごとの費用メモ、問題が起きたときの戻し方を同じリポジトリで扱っています。テンプレートが作れたかではなく、費用への影響と復旧方法を確認できるかを採否の基準にしています。

AIがAWSを自動で変更する仕組みではありません。費用が増える変更、既存環境を壊す変更、本番反映、復旧は人が判断します。インフラ経験をAIへ渡しながら、責任までAIへ預けないための境界です。

100日を終えて、kintoneエンジニアとして残ったもの

100日を完走できた原動力は、公開すると宣言し、連続記録を途切れさせたくなかったことです。

朝に作った日も、前日に準備した日も、やる気が落ちた時期もありました。公開工程の漏れを後から補った日も含め、100テーマ分の成果物、記事、概要動画を最後まで積み上げました。

100日後に残ったのは、「選択・順次・繰り返し」という基本を、AIとの開発でも実行できる進め方です

SIerとして経験してきた要件整理、役割分担、品質確認、差し戻し、引き継ぎを、100日間のAIとの開発にも当てはめました。AIには担当範囲と停止条件を与え、採否、本番反映、運用は人が判断します。

個人事業主としての目的は、AIを使うこと自体ではなく、AIを味方にお客様の問題を解決することです。kintone開発では、基本機能、既存製品、個別開発から課題と運用に合う手段を選びます。

kintoneの導入・カスタマイズや、AIを取り入れた開発については、課題整理の段階からご相談いただけます。対応範囲と依頼方法は、kintone導入支援ページにまとめています。

森田ユウゴ

ここまでご覧いただきありがとうございました！

各種お仕事のご依頼や、案件のご相談は下記をご覧ください！

森田ユウゴの技術スタックとポートフォリオ｜kintone・業務自動化・ツール開発

お問い合わせ

森田ユウゴ(Yugo Morita)

面倒解決エンジニア

XYouTubeContact

専門学校卒業後、新卒で大手ITベンダーに入社して約10年勤務、フルタイムで働きながら通信制大学を卒業。その後1年XR/メタバース関連企業で挑戦後、台湾のIT企業でプリセールスエンジニア(產品專員)として2年勤務。現在はフリーランスエンジニアとして、日本のお客様を中心にフルリモート(台湾から時差-1時間)でサービス提供。 kintone認定 アプリデザインスペシャリスト(2025), kintone認定 カスタマイズスペシャリスト(2026)を保持し、kintone開発に携わっています。プロダクトの価値を伸ばすカスタマイズの提案と実装が得意領域。AnkiカスタマイズやChromeアドオン開発にも熱中しています。尽きない好奇心とインフラ経験、AIであなたの「不便」を解決へ導きます。