製品

業務部門向け

HOZEN保全記録をもとに、原因調査と再発防止を支援。提供中 · 実証相談Millwright業務の手順を定め、AIをその範囲で動かす。AI-RPAは設計・検証段階

開発チーム向け

Hemkar人とAIの開発作業を、検証できる成果にまとめる。設計・開発段階FlashRouter複数のAIモデルの接続・版・利用量をまとめて管理。企業向けは個別相談IngaDB自社システムに組み込める因果分析データベース。v0.1.0 · セルフホスト · 提供中
ソリューション保全・品質改善過去の記録を、原因調査と再発防止に活かす。関連:HOZEN業務自動化・AI協働業務の手順と、人・AIの役割をそろえる。関連:Millwright · Hemkar企業AI基盤AIを使う条件を決め、構成と運用に反映する。関連:FlashRouterロボティクス・制御現場の条件に合わせて、ロボットと制御を設計する。関連:研究・開発テーマ
技術会社情報ニュース 導入を相談する

Hemkar人とAIの協働開発ワークスペース

現場のAI活用を支える基盤ツール設計・開発段階

人とAIの仕事を、 一つの成果へ。

人が目的を決め、AIと開発者が作り、人が証拠を確認する。Hemkarは、その計画・担当・報告・判断を共有し、別々の仕事を確認できる一つの成果につなぐ開発ワークスペースを目指しています。

HemkarのBoard画面。目的・成果・作業・判定がつながり、右側に選んだ作業の受け入れ条件と証拠が表示されている
開発中の画面デザイン案(Board と Inspector)。表示している人名・プロジェクト・作業は設計用の例です。

GitHubとClaude Codeで、十分では?

それで十分なら、管理ツールを増やす必要はありません。GitHubで課題・コード・履歴を管理し、Claude Codeに実装やテストを支援してもらう進め方でも、必要な情報と判断を共有できます。

ただ、複数の人やAIが参加すると、「誰に何を任せたか」「どの問いの回答を待っているか」「何を根拠に受け入れたか」を追う負担が増えます。Hemkarは、これらを一つの流れとして共有しやすくすることを目指します。

大切なのはツールを増やすことではなく、必要な人とAIが、同じ目的と根拠で次に進めることです。

共有するのは、作業の指示だけではない。

  • 目的と完成条件

    誰のために、何を作り、何ができれば完成か。

  • 担当と許可範囲

    誰が何を進め、どこまで変更してよいか。

  • 状況と問い・回答

    何が進み、何が不明で、誰の回答が必要か。

  • 結果と証拠

    どの条件を確認できたか。何が未確認か。

  • 判断と変更の経緯

    なぜその判断をしたか。次の担当が何を引き継ぐか。

作業は手元で。共有はHemkarで。判断は人が。

人のチームリーダー・開発者 レビュアー業務・要求の判断者 Hemkar計画から受け入れまでの共有記録 目的と完成条件担当と許可範囲問いと回答結果と証拠判断と経緯 手元のAI計画・実装・テストを支援 ブラウザーAIUATの証拠集め(想定) 目的・承認 確認待ち・証拠 回答・判断 業務の問い 計画・作業許可 報告・証拠 UATの証拠 判断は人が 共有はHemkarで 作業は手元のコンピューターで 人のチーム レビュアー 目的・承認・回答 問い・確認待ち Hemkar計画から受け入れまでの共有記録 目的と完成条件担当と許可範囲問いと回答結果と証拠判断と経緯 計画・作業許可 報告・証拠 手元のAI ブラウザーAI 作業は手元で・共有はHemkarで・判断は人が
設計上の概念図です。役割と情報の流れを示すもので、システム構成図ではありません。

AIの実作業は手元のコンピューターで行い、CLIで共有側とやり取りします。Hemkarはコードを実行する場所ではなく、合否は人が決めます。接続、計画の公開、作業開始の許可は、それぞれ別の段階です。

レビュアーの仕事は、
業務の問いに答えること。

ここでいうレビュアーは、ソースコードを読む人ではありません。開発者やAIだけでは決められない問いに、業務の立場から答える人です。たとえば売上CSVの開発なら、問われるのは次のようなことです。

「営業がこのCSVで確認したいことは何ですか?」

「売上日は、受注日と計上日のどちらを基準にしますか?」

「取消済みの売上は含めますか?」

「必要な列が一つ欠けています。この状態で受け入れますか?」

開発者とAIは、背景・選択肢・影響・推奨案・証拠を添えて、答えられる形に問いを整えます。ソースレビューや仕様との適合確認は、別の役割として扱います。

売上CSVの開発を、
計画から受け入れまで。

依頼は「売上をCSVで取り出したい」。最初に期間、必要な列、権限、合格条件を決めます。以下は架空の開発例です。

① 計画人が完成条件を決める ② 担当・実装AIが手元で作る ③ 検証人とAIで証拠を集める ④ 受け入れ業務責任者が判断する 差し戻し:列が足りない Hemkarに残るもの:計画と版 → 担当と作業権 → ログ・CSV・比較結果 → 判断者と理由
架空の開発例です。
STEP 1計画
STEP 2担当・実装
STEP 3検証
STEP 4受け入れ
人がすること
目的・期待値・対象外を決め、計画を承認する
作業範囲を許可し、設計・変更を確認する。必要なら自ら実装する
テストと期待値の十分さ、結果、残るリスクを確認する
業務責任者が合格・差し戻しを判断する
AIがすること
不明点を質問し、計画案を作る
着手できる作業を引き受け、コードを変更する
開発側のテストを実行し、UATの操作・証拠収集を支援する(想定)
差し戻し時は修正・再実行する
Hemkarに残すこと
完成条件、承認された計画と版
担当、作業権、進行状況
対象版、環境、ログ、CSV、比較結果、未確認事項
判断者と理由、次の作業、再確認結果
  1. ① 計画
    人
    目的・期待値・対象外を決め、計画を承認する
    AI
    不明点を質問し、計画案を作る
    Hemkarに残す
    完成条件、承認された計画と版
  2. ② 担当・実装
    人
    作業範囲を許可し、設計・変更を確認する。必要なら自ら実装する
    AI
    着手できる作業を引き受け、コードを変更する
    Hemkarに残す
    担当、作業権、進行状況
  3. ③ 検証
    人
    テストと期待値の十分さ、結果、残るリスクを確認する
    AI
    開発側のテストを実行し、UATの操作・証拠収集を支援する(想定)
    Hemkarに残す
    対象版、環境、ログ、CSV、比較結果、未確認事項
  4. ④ 受け入れ
    人
    業務責任者が合格・差し戻しを判断する
    AI
    差し戻し時は修正・再実行する
    Hemkarに残す
    判断者と理由、次の作業、再確認結果

「報告」「合格」「受け入れ」を、
区別して表示する。

Implemented

実装した。条件を満たしたとは限らない。

Reported

AIが報告した。まだ検証されていない。

Passed

個別のチェックに合格。ほかの条件は未確認。

Awaiting audit

人による成果の確認待ち。

ここから先は人が判断
Verified

対象の条件を検証した状態。

ダウンロードとテストが成功しても、完成条件に定めた列が欠けていれば差し戻し。

AIが止まったとき、
続けるか交代するかは人が決める。

AIの作業が止まったら、最後の報告と作業権の経緯を確認し、そのまま続けるか、担当を交代するかを人が決めます。

「Stale(停滞)」は古さを示す表示です。表示だけで担当が自動的に外れることはなく、手元の作業も消えません。

停滞した作業の画面。最後の報告と経緯が時系列で表示され、エージェントに続けさせるか、担当を解除するかを選べる
開発中の画面デザイン案(停滞した作業の確認)。

V字モデルは、そのまま使う。

Hemkarは、V字モデルに代わる工程モデルではありません。V字モデルが「何を何で確かめるか」を整理し、Hemkarが「誰が実行し、何を根拠に誰が判断したか」を共有します。

業務要求業務で何を使うかUAT・受け入れテスト業務で使えるか対応する確認システム要求・仕様範囲・権限・合格基準システムテスト全体が仕様を満たすか対応する確認部品の構成・接続部品と接続・リスク結合テスト部品の連携は正しいか対応する確認個々の処理の詳細処理・期待値単体テスト個々の処理は正しいか対応する確認 実装|開発者+AI許可された範囲でコードを変更 Hemkar|各段階のつながりと経緯を共有 目的・完成条件/担当・許可範囲・作業権/問い・回答/証拠・判断
決めること
対応
確かめること
業務要求業務で何を使うか
UAT・受け入れテスト業務で使えるか
システム要求・仕様範囲・権限・合格基準
システムテスト全体が仕様を満たすか
部品の構成・接続部品と接続・リスク
結合テスト部品の連携は正しいか
個々の処理の詳細個々の処理・期待値
単体テスト個々の処理は正しいか
Hemkar|各段階のつながりと経緯を共有目的・完成条件/担当・許可範囲・作業権/問い・回答/証拠・判断

対応は代表例で、名称や粒度は組織により異なります。

毎日は、判断が必要なところから見る。

Hemkarの画面デザイン案
Inbox人に必要な質問・確認・再開の判断を集める。

開発中の画面デザイン案です。表示している人名・プロジェクト・作業は設計用の例で、実際の稼働状況ではありません。

リーダーと開発者の仕事は、
こう変わる。

リーダーの重心

進捗を聞くだけでなく、仕事が止まる原因と、判断の分担を整える。

開発者の重心

手で書く作業に加え、AIの案を比較・修正・検証し、保守できる成果にする。

変わらないこと

技術判断、設計、コード理解、検証、説明の責任。自分が入力していないコードでも確認を省略しない。

既存のツールとは、
管理の重点が違う。

Microsoft Project/Planner工程、日程、依存関係、リソース。いつ終わり、誰をどこに配置するか。
Backlog課題、担当、進捗、チームのやり取り。誰が何を担当し、どこまで進んだか。
Jira課題とワークフロー。仕事をどの状態・手順で進めるか。
Notion課題、文書、知識、AI支援。組織の仕事と知識をどうつなぐか。
Hemkar人とAIの作業範囲、証拠、判断。何を任せ、何を根拠に受け入れるか。

併用する場合は、Projectで工程、Backlog/Jiraで課題、HemkarでAI協働の経緯を扱う分担が考えられます。外部サービスとの自動連携は今後の構想です。比較は重点の違いを示すもので、優劣の評価ではありません。各製品の名称は各社の商標です。

よくある質問

人はAIの承認係になりますか?
いいえ。目的、設計、コード理解、テスト、業務判断の責任は人に残ります。
Verifiedなら、すべて正しいと保証できますか?
いいえ。対象の条件を検証したことを示すもので、未確認の範囲まで保証しません。
レビューだけ参加する人も、CLIが必要ですか?
不要です。招待されたアカウントでブラウザーから参加する設計です。
今すぐ本番で使えますか?
本ページは設計紹介です。利用可能な範囲、検証方法、提供時期は個別にご確認ください。